Migrate from Agworld to Salesforce Sales Cloud

Agworld API rate limit of 200 requests per minute constrains bulk extraction speed

Agworld's API enforces a hard rate limit of 200 requests per minute and 5,000 requests per hour, with a maximum of 4 concurrent calls. Large farms with thousands of fields and multi-year activity histories will find that the discovery extraction phase takes longer than comparable CRM migrations. We handle this by monitoring X-RateLimit-Remaining headers, sizing batches to stay well below 200/minute even under concurrent load, and using pagination to avoid single large-page requests that consume disproportionate rate-limit budget. The migration plan documents exact batch sizing and throttle settings for your record volume so the full export completes predictably.

Agworld's field-centric activity model has no native Salesforce equivalent and requires a custom junction object

Agworld activities (spraying, fertilizing, harvesting) are inherently tied to a field — the field context is part of the activity record. Salesforce Tasks are standalone objects that can be attached to an Account or Contact but cannot natively link to a custom Field__c record. If you filter Agworld by 'all activities on Field X', there is no direct Salesforce equivalent for that relationship without a junction object. We resolve this by creating a custom Field_Activity__c junction object with lookups to both Task and Field__c. Every activity migrated from Agworld gets a corresponding Field_Activity__c record during migration so your team can report 'activities per field' in Salesforce exactly as they did in Agworld. This requires a custom object and Lightning page component to display the junction in the Field__c page layout.

Spray records and chemical application data must migrate as a custom compliance object

In agricultural operations, spray records are not optional — they are required by law for food safety audits, GAP (Good Agricultural Practice) certification, and buyer due-diligence questionnaires. Agworld stores these as typed Activity records with product name, application rate, weather conditions, wind speed, temperature, and applicator recorded. Salesforce has no standard compliance record object for chemical applications. We create a custom Spray_Record__c object with all the relevant chemical-application attributes as custom fields, linked to Field__c via a lookup. This object is queryable for compliance reporting. If your operation uses Agworld's compliance exports for processor or auditor submissions, rebuilding that reporting output in Salesforce is a post-migration configuration step.

All Agworld integrations (Figured, John Deere Operations Center, Greenbook) break after migration and require a rebuild plan

Agworld connects to precision-ag tools and financial platforms including Figured (farm financial management), John Deere Operations Center (equipment data), Greenbook (chemical database), and PCT AgCloud. These integrations are built on Agworld's API and break completely once you stop using Agworld as your primary record system. Salesforce has no direct replacement for these connections out of the box. We document every active Agworld integration during the discovery phase and provide a rebuild plan that identifies whether each tool has a Salesforce-native connector, an AppExchange app, or requires a middleware platform (Zapier, Workato, custom API) to re-establish the data flow. This is a manual rebuild effort that is not included in the standard data migration scope.

GPS polygon boundary data requires WKT transformation — Salesforce has no native geometry field

Agworld stores field boundaries as GPS polygon geometry with centroid coordinates. Salesforce has no native geospatial geometry field type on custom objects. Storing polygon data requires a transformation step: we convert the Agworld GPS polygon to Well-Known Text (WKT) format and store it in a Field_Boundary__c Textarea field on the custom Field__c object. The centroid is stored as separate Latitude__c and Longitude__c custom number fields. WKT enables third-party mapping apps from the AppExchange (such as MapAnything or Egon CRM Maps) to render field boundaries on the Field__c record page. This adds a transformation step to the migration pipeline that does not exist for standard CRM field mapping.