What does a Salesforce data migration involve?
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.
Signs you need a migration to Salesforce
- You have outgrown HubSpot, Dynamics or a legacy CRM.
- Sales and support run in separate systems you want to consolidate.
- You are moving from Salesforce Classic to Lightning.
- Marketing lives in a tool that does not talk to your CRM.
What we deliver (5)
Source analysis
An inventory of objects, fields, volumes, duplicates and data quality in the old system.
Mapping
Field and object mapping agreed with the business, including what not to bring over.
Cleanup
Deduplication and standardization before load, not after.
Test loads
Trial migrations into a sandbox with record-count and spot-check reconciliation.
Cutover
A dated plan for the final load, freeze window and go-live support.
Migration, phase by phase (4)
What happens in each phase, what you get at the end of it, and what we need from your team.
- 01
Inventory
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.
- 02
Map
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.
- 03
Test
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.
- 04
Cut over
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.
What drives the effort in a migration (6)
| 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. |
Rates typically range from $185 to $225 per hour depending on scope and expertise required, and you get a written estimate after discovery, so these factors are what we ask about first.
Related client work (11)
More migration client work
- An insurance agency replaced Google Sheets with Sales Cloud and strict per-agent record privacyInsurance
- A building-products manufacturer unified trade-show marketing and sales with Marketing CloudManufacturing
- A payments ISO replaced two legacy systems with a Sales, Service, and Experience Cloud platform for 60+ agentsFinancial Services / Payments
- An event-production company consolidated six tools into one custom Sales Cloud workflowMedia & Event Production
- A 28-year technology consultancy stood up Sales Cloud and Marketing Cloud for a growth relaunchTechnology Consulting
Common migration mistakes (4)
- 01
Treating migration as an export-import job
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.
- 02
Bringing every field across
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.
- 03
Skipping a rehearsal against real volume
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.
- 04
Forgetting what depends on the old system
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.
Questions to ask before you sign (5)
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.
- 1
How do you prove every record arrived correctly?
Expect a specific reconciliation method: counts by object, checksums or totals on key numeric fields, and sampled side-by-side record checks with business users. An answer that relies only on the import tool reporting success is a warning sign, since silent truncation and mismatched lookups are common.
- 2
What is your plan if the final load fails partway?
Good partners describe a rollback or resume approach, such as external IDs that allow safe reloads without duplicates and a decision point for reverting to the old system. They should also explain how automations are paused so a failed run does not trigger emails.
- 3
How do you handle duplicates across multiple source systems?
Listen for matching logic beyond exact email or name, a survivorship rule for which values win, and business review of borderline matches. A partner who proposes deduplicating after the load is pushing a hard problem onto your users.
- 4
Which tools do you use for loading, and why?
There is no single right tool, but a strong answer explains the choice: Data Loader or Bulk API for volume, an ETL tool for repeatable transformations, and scripted loads that can be rerun identically. Improvised spreadsheets passed between people make results hard to reproduce.
- 5
What happens to data you do not migrate?
The partner should help you decide what is archived, where it lives, and how someone can find an old record later. Legal or regulatory retention rules may apply. Simply abandoning the old system leaves compliance gaps and frustrated users hunting for past context.
Products, industries and markets
Salesforce products we work with here
Migration by industry
Industries where we have delivered migration
Markets where migration is a common need
Guides on salesforce migration (10)
- Spreadsheets to Salesforce: A Practical Migration PlanMigration · 8 min read
- Zoho CRM to Salesforce Migration: A Practical GuideMigration · 8 min read
- Pipedrive to Salesforce Migration: A Practical GuideMigration · 8 min read
- Dynamics 365 to Salesforce Migration: A Practical PlanMigration · 7 min read
- Salesforce Migration Cost Drivers: What Raises EffortMigration · 8 min read
- Merging Salesforce Orgs After an AcquisitionMigration · 7 min read
- HubSpot to Salesforce Migration: A Practical GuideMigration · 7 min read
- Salesforce data migration checklist: from scoping to cutoverMigration · 5 min read
- Data Import Wizard vs Data Loader: Safe Salesforce ImportsMigration · 8 min read
- Salesforce Go-Live Checklist: Cutover and HypercareImplementation · 6 min read
Salesforce Migration questions (9)
How long does a HubSpot to Salesforce migration take?
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.
Will we lose email history and activity data?
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.
Can you migrate our marketing automation too?
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.
Should we clean data before or after migrating?
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.
Can we keep using the old system during the migration?
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.
How do you keep record IDs and relationships intact?
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.
Can you move data from one Salesforce org to another?
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.
What happens to created dates and record owners?
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.
Do we need to migrate before implementation is finished?
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.