CRM Migration Checklist: Moving Off Salesforce or HubSpot Without Losing Data
A step-by-step checklist for migrating CRM data from Salesforce or HubSpot to a new platform, covering audit, field mapping, cleanup, test migration, and cutover.
Last updated July 18, 2026
Why CRM migrations fail
Most failed CRM migrations aren't caused by the software — they're caused by migrating messy data as-is and skipping validation. A team exports everything from Salesforce or HubSpot, imports it into the new system, and only discovers weeks later that half the deals lost their contact associations, three custom fields didn't map anywhere, and the lead routing rules never got rebuilt. By then reps have already started keeping their own spreadsheets again, which defeats the point of switching CRMs at all.
The checklist above front-loads the two steps that get skipped under time pressure: cleaning data before export, and running a test migration before the real one. Both add time upfront and save far more time on the back end.
The most common mistake
Migrating directly from production to production, with no test batch and no sandbox check, is the single biggest predictor of a failed migration. Any gap in field mapping or broken relationship shows up in every record instead of a sample of a few hundred.
What to audit before exporting anything
List every object type in use (contacts, companies, deals/opportunities, tickets, custom objects), every custom field on each, every active automation or workflow, and every connected integration. Salesforce orgs in particular accumulate custom fields and validation rules over years that nobody remembers the purpose of — this audit is where you decide what's worth carrying forward.
Example
A financial advisory firm migrating off Salesforce found 40 custom fields on the Contact object, but reps only actively used 11 of them. The other 29 were legacy fields from a compliance process retired three years earlier. Dropping them shortened the field-mapping table from 40 rows to 11.
How to handle data that doesn't map cleanly
Some source fields won't have a direct equivalent in the new CRM. Decide, field by field, whether the data becomes a new custom field, gets appended to a notes field, or gets dropped as no longer useful. The wrong approach is discovering this mid-migration and improvising — decide it during the audit, before any records move.
Record relationships deserve the same scrutiny as fields. A deal linked to three contacts and one company in Salesforce needs those same four relationships to survive in the new system. Flat CSV exports often lose this structure, which is why an API-based or native import tool that preserves relationships is worth the extra setup time over a plain spreadsheet export.
Why a test migration matters more than the real one
A test migration into a sandbox or isolated workspace is the only reliable way to catch mapping errors before they touch every record. Pick a meaningful sample — one rep's full pipeline, or a random few hundred contacts — and check it against the source system field by field: record counts match, relationships intact, custom field values landed where expected, and historical activity came across.
Example
A recruiting agency ran a test migration of one recruiter's 200 active candidates before migrating the full database of 15,000. The test surfaced that resume attachments weren't transferring — a fix applied before the full migration ran, instead of after 15,000 records needed re-uploading.
Why parallel running beats a hard cutover
Switching every user over to the new CRM the same day the old one goes read-only leaves no room to catch problems. Running both systems in parallel for one to two weeks — old system read-only, new system live — gives the team a window to notice a missing automation or an unmapped field while there's still a source of truth to check against and fix before full decommission.
Set a hard decommission date
Open-ended parallel running tends to stretch indefinitely because it's more comfortable than fully committing to the new system. Pick a specific cutover date at the start, and only extend it if the team surfaces a real blocking issue, not general hesitation.
What to migrate versus archive
Not every historical record needs to make the trip. Active contacts, open deals, and the last 12-24 months of activity history carry real value in the new CRM. Closed-lost deals from five years ago and long-dead leads mostly add clutter and cleanup work without helping anyone close business today. Export and archive that older data outside the CRM — a CSV backup is sufficient — rather than importing it wholesale.
Rebuilding automations instead of just data
Data migration gets most of the attention, but a CRM is only as useful as the automations running on top of it. Lead routing rules, follow-up sequences, deal-stage notifications, and approval workflows all need to be rebuilt natively in the new system rather than assumed to carry over. Salesforce Apex triggers and HubSpot workflows in particular don't export in any reusable form — they have to be recreated from scratch based on what the team documented during the audit step.
Test each rebuilt automation against real records before cutover, not just against a demo record. A lead-routing rule that correctly assigns a test lead named "Test Testerson" can still fail silently on a real lead with a blank field the rule didn't anticipate.
Example
An HVAC company migrating from HubSpot rebuilt its lead-routing workflow to assign new leads by service area. Testing against 20 real leads from the previous month caught that leads without a ZIP code — about 8% of the sample — fell through to no owner at all, a gap the original HubSpot workflow had silently handled with a default assignee.
Handling third-party integrations
Most CRMs connect to email, calendar, phone systems, marketing tools, and sometimes accounting or e-signature software. Each of these integrations needs to be re-authenticated and reconfigured in the new CRM, and each one is a separate point of failure during cutover. Build a simple inventory during the audit step: what's connected, what data flows in which direction, and who owns that integration internally.
Reconnect and test integrations before the parallel-running period starts, not during it. An email sync that silently stops logging messages for a week is much harder to notice and recover from than one caught in a dedicated testing pass.
Communicating the migration to the team
A migration plan that only exists in an admin's head fails the moment reps hit friction and route around the new system. Tell the team the cutover date, what stays the same, what changes, and where to report problems during the parallel-running window. Reps who know a rough date and a clear escalation path stick with the new CRM through early rough edges; reps who are surprised by a sudden switch tend to fall back to spreadsheets or their inbox instead.
Assign one migration owner
Migrations that get treated as a shared responsibility across the team tend to stall — nobody feels accountable for the field-mapping table or the test migration. Naming one person as the migration owner, even at a five-person company, keeps the checklist from stalling between steps.