Photo: Tim van der Kuip / Unsplash
We move companies onto Salesforce from HubSpot, Microsoft Dynamics, marketing tools and homegrown systems, and between Salesforce products. The work that matters most happens before any data moves: mapping, cleanup and a cutover plan the business can live with.
A Salesforce migration moves records, relationships and history from an old system into Salesforce. It involves mapping fields and objects, cleaning and deduplicating data, deciding what history to keep, loading data in the right order, reconciling counts afterward and planning a cutover so the team is not working in two systems at once.
An inventory of objects, fields, volumes, duplicates and data quality in the old system.
Field and object mapping agreed with the business, including what not to bring over.
Deduplication and standardization before load, not after.
Trial migrations into a sandbox with record-count and spot-check reconciliation.
A dated plan for the final load, freeze window and go-live support.
What happens in each phase, what you get at the end of it, and what we need from your team.
We connect to the source system, whether that is another CRM, a marketing platform or a shared drive of spreadsheets, and profile what is really there. That means record counts per object, fill rates for each field, duplicate clusters, orphaned child records, attachment volumes and any custom tables nobody has documented. We also note API limits and export options, because some older systems only give up their data slowly or in awkward formats.
Every source field is assigned a destination, a transformation or a decision to leave it behind. Picklist values get translated, owners get matched to new users, and relationships are rebuilt so contacts land under the right accounts and activities attach to the right deals. We agree on a survivorship rule for duplicates, deciding which record wins and which values merge, and set a cutoff date for how much closed or stale history travels.
We run complete trial loads into a full or partial copy sandbox, then reconcile. Counts are compared object by object, and a sample of records is opened side by side with the source to confirm values, owners, dates and related lists came across intact. Load failures are traced to their cause, whether a validation rule, a missing lookup or a bad value, and fixed in the scripts. We repeat until a run finishes clean and inside the planned window.
The old system goes read-only at an agreed moment, a final delta or full load runs, and reconciliation repeats against production. Integrations and automations that were paused during the load are switched back on in sequence so they do not fire on migrated records. Users log in to find their data where they expect it, and we stay on hand to fix stragglers, reassign ownership and answer the inevitable questions about where something went.
The same work can be a small project or a large one. These are the factors that decide which.
| Factor | Keeps effort down | Raises effort |
|---|---|---|
| Number of source systems | A single CRM with its own export tools and a mostly standard schema. | Several tools, such as a CRM, a marketing platform and spreadsheets, that each hold overlapping versions of the same customers. |
| Record volume | Thousands of records that load quickly and can be spot-checked by hand. | Millions of records needing Bulk API loads, batching and careful attention to automation and storage limits. |
| Activity and file history | Only open deals and recent activity move, with older history archived elsewhere. | Years of emails, notes and attachments that must stay linked to the right records and remain searchable. |
| Data quality | Consistent formats, few duplicates and clear record owners already in the source. | Heavy duplication, free-text fields holding structured data, and records owned by people who left long ago. |
| Custom objects and relationships | Standard accounts, contacts and opportunities connected by simple parent-child lookups that map directly. | Custom tables, many-to-many relationships or product and pricing structures that need rebuilding in Salesforce's model. |
| Cutover constraints | A quiet weekend freeze that sales, service and finance can absorb without complaint. | Operations that never fully stop, regional teams or linked systems that cannot pause, requiring delta loads and staged switchover. |
We price from a written scope after discovery, so these factors are what we ask about first.
Dumping a CSV from the old system and pushing it through the import wizard skips relationships, ownership and history. Contacts end up detached from accounts, activities lose their context, and users stop trusting the new CRM on the first morning. A migration is an engineering exercise with dependencies, load order and reconciliation, not a file transfer.
Old systems accumulate fields added for one campaign, one manager or one report that nobody reads. Migrating them all clutters page layouts, confuses users and complicates future automation. Reviewing fill rates usually shows a long tail of empty or abandoned fields. Leaving those behind, with an archived copy for reference, gives the new org a clean start.
A test with a hundred records proves the mapping works; it does not prove the full load fits inside the cutover window or survives validation rules, triggers and storage limits at scale. Running at least one timed rehearsal with complete data exposes the slow objects and failure points while there is still time to fix them calmly.
Web forms, marketing lists, billing exports and scheduled reports often point quietly at the legacy CRM. If nobody catalogs them, leads go missing the day after cutover. When a marketing firm moved its sales cadences off another tool, planning for lead routing and dialer connections up front helped it finish with zero disruption and 100% rep adoption.
A migration partner earns its fee in the details that do not show up in a demo: reconciliation, rollback plans and the judgment to leave bad data behind. These questions help you tell a team that has moved messy real-world data from one that has mostly run clean imports.
Written by the consultants delivering the work.
How to move a team off Excel or Google Sheets into Salesforce: inventory the files, map columns to objects, clean and load, rebuild reports, archive the originals, cut over and stop shadow spreadsheets.
Read the full post →For a compliance-software company with under 8,000 accounts, the migration took 4–6 weeks, including marketing automation and MQL-to-SQL handoffs. Larger data sets and more integrations take longer.
Not if it is planned. We decide with you which activities, emails and attachments are worth moving, and archive the rest in a way you can still reach.
Yes. We have moved a renewable-energy company off MailChimp with 29,000+ prospects migrated into Marketing Cloud Account Engagement, and a regional bank off ActiveCampaign.
Before. Loading duplicates and bad data into a new system carries the old problems forward and erodes trust in the new one on day one.
Yes, for most of it. Inventory, mapping and trial loads all run against copies or read-only exports, so daily work continues as normal. The only disruption is a short freeze just before the final load, when edits in the old system stop so nothing is lost between extract and import. For teams that cannot pause, we use delta loads that pick up changes made after the main extract.
Salesforce generates its own record IDs, so we store each legacy ID in an external ID field on the new record. Child records are then loaded by referencing that external ID, which rebuilds links between accounts, contacts, opportunities and activities reliably. Keeping the legacy ID also lets anyone trace a record back to its source and allows safe reloads that update rather than duplicate.
Yes. Org-to-org moves come up after acquisitions, when business units consolidate, or when a company wants a clean org instead of repairing an old one. The data work is similar to any migration, but metadata matters too: fields, automation and permissions may need to be rebuilt or deployed first. Differences in record types and picklist values between the two orgs usually drive most of the mapping effort.
Both can be preserved. Salesforce allows original created and last-modified dates to be set during import when the right permission is enabled, so reports on deal age and account tenure stay meaningful. Owners are matched to new user accounts by email or a lookup table. Records belonging to former employees are reassigned according to a rule you approve, such as territory or a default manager.
No. The final migration should happen once the destination org is stable, because loading data into a moving target creates rework. Mapping and trial loads, however, should run in parallel with the build. Early trial loads catch fields the design missed and give testers realistic records, so the two workstreams keep informing each other right up to cutover and neither is surprised on launch day.
A Salesforce Health Check reviews your org and gives you a ranked list of what to fix first, with effort estimates. It is the right starting point before an optimization project, a new cloud or an AI initiative.
Headquartered in St. Louis, working with companies across the U.S.
Discuss your migration →Tech Talk
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.