Farm operations rarely map neatly to accounts, so we untangle growers, entities, fields and dealer relationships before a single season of history is loaded.
An agriculture migration usually starts from a patchwork: grower lists in spreadsheets, agronomy notes in a separate app, dealer contacts in an older CRM and order history in the ERP. We consolidate those into one Salesforce model where each farm operation is an account, each decision-maker is a contact, and fields, acreage and crop plans hang off the right grower. Duplicate operators are merged by legal entity rather than by name, seasonal history is loaded so reps can see what was bought last spring, and cutover is timed away from planting and harvest so field teams are not learning new screens in their busiest stretch.
Farm customers rarely fit a clean account-and-contact pattern. One family may run several legal entities, rent ground from landlords, and buy through more than one dealer or retail location, so a naive import produces either duplicates or wrongly merged operations. Agronomic data adds another layer: fields, soil samples and crop plans belong to a location and a season, not just a customer. Source data is often typed into spreadsheets by territory managers with their own conventions for names and units. And the calendar sets the schedule. A migration that lands during spring sales or harvest delivery competes with the work that pays for it, so timing is part of the design rather than an afterthought.
Territory spreadsheets often list the same farm under a nickname, a family member and a business entity. We match on tax entity, mailing address and billing account from the ERP, then review borderline matches with the sales managers who know the growers. The result is a single operation record with related entities and contacts, so credit, rebates and relationship history roll up correctly.
Where acreage, field names or crop rotations are tracked today, we load them as related records under the grower and tag each one by season. Units are normalized to a single standard, retired fields are flagged rather than dropped, and every field keeps its link to the operation that farms it, even when a landlord owns the ground and the operator changes.
Reps plan the next season from what a grower bought, booked early and earned in programs last year. We bring summarized purchase history, early-order bookings and rebate participation across from the ERP or order system, keyed to the correct operation. Line-level detail stays in the system of record, and Salesforce shows the totals reps actually use in planning conversations with each grower.
Manufacturers and input suppliers selling through dealers need each grower tied to the location that serves them. We load dealer accounts, branch locations and territory assignments, then map grower relationships to the right branch so channel reports, co-op programs and lead handoffs work from the first day, instead of relying on a veteran rep's memory of who covers which county.
We run agriculture migrations backward from the season. The first conversation with sales and agronomy leaders sets the cutover window, usually the quieter stretch after harvest settlement. Territory managers help build the matching rules because they know which names are the same operation. Test loads go into a sandbox, and a small group of reps checks their own growers before anyone else sees the data. The legacy spreadsheets are frozen read-only at cutover, not deleted, so any grower record that looks wrong can be traced back to its source during the first selling season on the new platform.
Customer numbers, credit status and invoiced sales are the anchor for matching growers. We extract them first, load summaries into Salesforce and keep the ERP as the owner of every transaction.
Field records, soil tests and crop plans are mapped by season and field identifier, so agronomic history lands under the right operation instead of arriving as loose attachments.
Early-order bookings and program enrollments are matched to dealer locations and growers, giving reps last season's commitments alongside open opportunities for the next one.
Cutover during planting, spraying or harvest delivery means reps will keep using the old spreadsheets out of necessity. Pick a window when field staff can attend training and check their own records, and schedule the final load so the new system is trusted before the next early-order push begins.
Agronomic and yield data often comes with contractual limits on how it is shared or used. Review those terms before loading it, restrict visibility to the teams permitted to see it, and document which records came from which source so future questions about consent have an answer.
Old seasons carry prices, products and territories that no longer exist, and loading every year clutters reports without helping reps. Most teams keep a few seasons of summarized history in Salesforce and leave older detail in an archive that can still be searched when a question comes up.
Yes, and that is the most common starting point in agriculture. We collect every version, standardize columns and units, and run matching across all of them before anything is loaded. Conflicts, such as two phone numbers or two different acreage figures for one farm, go back to the reps who own those relationships to resolve, rather than being settled by whichever file was imported last.
Visit notes and scouting reports can come across as activities or custom records tied to the grower and the field. We keep the author and date, clean out formatting that will not survive the move, and attach photos or reports where the source keeps them. Notes with no identifiable grower go to a review list instead of being loaded blindly into the wrong operation.
It is possible but rarely wise. Reps are booking orders and answering growers in the field, and a mid-season switch forces them to check two systems. If timing cannot move, we migrate a single region or team first, keep others on the legacy tools until the season closes, and then bring the rest across with lessons from the first group.
Usually not directly, unless a grower portal is part of the project. What they notice is a rep who already knows their operation, last year's purchases and pending programs when they call. If a portal is planned, clean contact and entity data from the migration is what lets each grower see only their own records and nobody else's.
One onshore team with 150 Salesforce certifications, a Salesforce Consulting Partner since 2017.
A monthly brief for the people who own Salesforce, AI and revenue technology
What changed in Salesforce and AI this month, and what to do about it.
One email a month. Written by the consultants who deliver the work, not by a marketing team, for the leaders who make the technology decisions.
Consultant analysis, not vendor recaps. One click to leave.