CRM Migration Checklist: The Complete Safety Protocol
Every step, in order, across four phases โ audit, mapping, execution, and verification. Print it, copy it into a project doc, or just use it to sanity-check a quote you've already received.
Quick answer: A complete CRM migration checklist covers four phases: pre-migration audit (data quality, field inventory, integrations list), field mapping and planning, staged execution with verification at each step, and post-migration checks (record counts, automation testing, team training). Skipping the audit phase is the single most common cause of migration problems.
Phase 1 โ Pre-Migration Audit
- Export a full record count by object type (contacts, companies, deals) from the current system
- Identify and flag duplicate records
- Identify dead/stale records (no activity in 2+ years) and decide whether to migrate or archive them
- List every custom field currently in use, with a note on what each one actually means
- List every active automation, workflow, or sequence
- List every tool integrated with the current CRM (email, billing, calendar, webinar platform)
- Confirm who has admin access to both the old and new systems
- Set a target go-live date and identify any hard deadlines
Phase 2 โ Field Mapping & Planning
- Map every custom field to its destination field, one by one โ no "figure it out during import"
- Flag fields with no direct equivalent in the new system and decide how to handle each
- Document tag/segmentation logic and how it maps to the new platform's structure
- Write out the automation rebuild plan โ trigger, condition, and action for each one
- Confirm pipeline/deal stage mapping if migrating active deals
- Decide the migration order (contacts first, then deals, then automations is typical)
- Get sign-off on the mapping plan before touching live data
Phase 3 โ Execution
- Run a test migration with a small data sample first
- Verify the test sample against the mapping plan field-by-field
- Migrate contacts/companies, then verify record count matches
- Migrate deals/opportunities, then verify record count matches
- Rebuild automations natively โ do not attempt to import automation logic directly
- Reconnect every integration identified in Phase 1, one at a time
- Test each reconnected integration with a real (not sample) transaction
- Keep the old system live and unchanged as a fallback during this phase
Phase 4 โ Verification & Handoff
- Compare final record counts (old vs. new) by object type
- Spot-check a random sample of records field-by-field, not just by count
- Send a test lead through the full funnel to confirm every automation fires correctly
- Confirm reporting/dashboards reflect the new system's data accurately
- Train the team on what's changed, not just how to log in
- Document the new system's structure and mapping decisions for future reference
- Set a date to fully retire the old system โ don't cancel it same-day
Want us to run this checklist for you? Every migration we deliver follows exactly this process โ fixed quote after a free audit call.
See CRM Migration ServicesPlatform-Specific Notes
The four phases above apply regardless of destination platform, but a few things differ:
- HubSpot: Standardized field structure makes Phase 2 mapping faster than most alternatives.
- Salesforce: Custom objects and validation rules add real time to Phase 2 โ budget extra time here specifically.
- GoHighLevel: Automation rebuild (Phase 3) tends to take longer given its combined CRM/funnel/booking structure.
- Pipedrive: Deal-centric structure simplifies Phase 2 for most sources migrating in.
Frequently Asked Questions
What should be on a CRM migration checklist?
Four phases: pre-migration audit, field mapping and planning, staged execution with verification, and post-migration checks including team training.
Is there a different checklist for HubSpot vs. Salesforce?
Same core phases, but Salesforce needs extra steps for custom objects and validation rules, while HubSpot typically moves faster due to its standardized structure.
How do I verify no data was lost?
Compare record counts by object type before and after, and spot-check a sample of records field-by-field rather than relying on the count alone.
Should I migrate everything or leave old data behind?
Dead or clearly outdated records are usually better cleaned up before migration โ migrating a mess just creates a smaller mess in the new system.