A CRM migration is not complete when customer records appear in the new system. It is complete when sales, service and marketing teams can trust the records, relationships, history, permissions, reports and workflows they need to do their jobs. A rushed import can preserve contact names while losing account hierarchies, opportunity history, ownership or the logic behind automated processes.
This CRM data migration checklist is designed for organisations moving between CRM platforms, consolidating multiple instances or replacing spreadsheets and disconnected sales tools. It focuses on the decisions that most affect migration risk, implementation cost and user disruption.
1. Define the migration outcome before selecting data
Start with the business reason for moving. Common objectives include consolidating multiple CRMs, improving pipeline visibility, reducing administration, integrating sales and service, or retiring a platform that no longer fits the operating model. Translate the objective into measurable outcomes such as improved account completeness, fewer duplicate records, reliable pipeline reporting or reduced manual handoffs.
Agree the scope with sales operations, marketing, customer service, finance, IT, compliance and the implementation partner. Record what is in scope, what is excluded, who approves exceptions and who owns the final data.
- Identify every source: production CRM instances, spreadsheets, marketing automation, customer service tools, partner portals and relevant databases.
- Inventory objects and record types: accounts, contacts, leads, opportunities, cases, activities, products, quotes, notes, attachments and custom objects.
- Decide whether to migrate all history, a defined time period, open transactions only or selected records based on business value and retention obligations.
- Define success measures and acceptance thresholds before the first test load.
2. Profile and clean the source data
Do not treat migration as a cleansing project that can be completed after extraction. Profile the source data early to quantify duplicates, missing fields, inconsistent formats, inactive records, invalid email addresses, obsolete owners and conflicting account names.
Establish data rules with business owners. For example, decide whether two accounts with similar names are duplicates, how to standardise country and state values, how to handle generic email addresses and whether inactive contacts should be retained. Avoid deleting records simply because they look old; legal retention, open opportunities, service history or account relationships may make them relevant.
- Measure completeness for fields required by the new CRM and critical reports.
- Define duplicate matching rules using more than one attribute where appropriate.
- Standardise picklists, currencies, dates, phone numbers, addresses and naming conventions.
- Assign a business owner to resolve ambiguous or conflicting records.
- Keep a documented exception file for records that cannot be cleaned automatically.
3. Map fields, objects and relationships
Field mapping is a business-design exercise, not just a spreadsheet exercise. A source field may have a different meaning, validation rule or level of detail in the target CRM. Mapping a legacy “status” field directly to a new status field without reviewing the lifecycle can produce misleading pipeline and service reports.
Create a mapping specification for every in-scope object. Include the source field, target field, transformation rule, mandatory status, default value, data owner and validation method. Identify fields that will be retired, combined, split or recreated as custom fields.
Plan record relationships and load order. Parent accounts generally need to exist before child records can be associated; users, teams and reference values may also need to be configured before transactions are loaded. Where a target platform uses new record IDs, preserve a legacy identifier or external ID so that related records can be matched and reconciled. Salesforce documentation, for example, explains the importance of preparing the target organisation and preserving relationships when moving data between orgs: Salesforce migration guidance.
4. Rebuild the operating model, not just the records
Review the configuration that makes the CRM useful: sales stages, lead qualification, assignment rules, approval flows, email templates, dashboards, service queues, territory structures, security roles and integrations. Some legacy automation may no longer be needed; other processes may need redesign because the target platform handles them differently.
For each workflow, document the business trigger, expected result, exception path, owner and test case. Confirm whether integrations should be paused during data loads and how records created during the migration window will be captured. Do not assume a migrated workflow will behave identically in a different platform.
5. Run a pilot migration and repeatable test cycles
Start with a representative sample rather than loading the entire database. Include clean and difficult records, multiple currencies, parent-child relationships, custom fields, attachments, inactive owners and edge cases. The pilot should test the full process from extraction through transformation, import, reconciliation and user review.
Use a non-production environment where available. Record load duration, error rates, rejected rows, duplicate creation, relationship failures and manual remediation effort. Correct the mapping or source data, then repeat the test. A successful pilot is evidence that the process is repeatable; it is not proof that every production edge case has been covered.
6. Reconcile the results with business owners
Record counts alone are insufficient. Reconcile totals by object, status, business unit and other meaningful dimensions. Compare samples field by field, verify parent-child relationships, inspect ownership, and test the reports users rely on. Check that open opportunities, cases and activities remain actionable rather than merely present.
- Compare source and target counts and explain every variance.
- Validate critical fields, currencies, dates, owners and record relationships.
- Review rejected records and confirm whether they are corrected, excluded or accepted as exceptions.
- Test duplicate detection, search, security permissions, dashboards and integrations.
- Obtain sign-off from business owners, not only the technical migration team.
7. Plan cutover, rollback and the first weeks after launch
Define a cutover runbook with named owners, a change-freeze window, final extraction time, delta migration approach, validation checkpoints, communication plan and go/no-go authority. Decide how transactions entered during the freeze will be handled. If the old CRM remains accessible for reference, define who can access it and for how long.
Set explicit rollback criteria. A rollback plan should state what failure would trigger a reversal, who makes the decision, how the source system is restored or reopened, and how new transactions are reconciled. A backup without a tested recovery procedure is not a complete rollback plan.
After launch, monitor integration failures, duplicate creation, missing ownership, user access issues, data-quality exceptions and adoption. Provide a clear support channel and daily issue triage during the initial stabilisation period.
CRM migration checklist: readiness gates
| Gate | Evidence required | Owner |
|---|---|---|
| Scope approved | Source inventory, objects, retention rules and success measures | Business sponsor |
| Data prepared | Profiling results, cleansing rules and exception log | Data owners |
| Mapping signed off | Field/object mapping and relationship design | CRM architect and process owners |
| Test migration passed | Repeatable load, error log and reconciliation results | Migration lead |
| Business acceptance | Validated reports, workflows, permissions and user scenarios | Department leads |
| Cutover authorised | Runbook, rollback criteria, communications and support coverage | Steering group |
How much does CRM migration cost?
Cost depends on the number of source systems, record volumes, data quality, custom objects, attachments, automation, integrations, security complexity and the amount of history that must be retained. A relatively simple contact-and-account import is materially different from consolidating several CRM instances with custom workflows and years of activity data.
Budget for discovery, cleansing, mapping, migration tooling, test cycles, integration changes, business-user time, training, cutover support and post-launch remediation. The largest avoidable cost is often not the data transfer itself but late discovery of unclear ownership, poor data quality or undocumented business logic.
Questions to ask a CRM migration partner
- How will you profile and quantify source-data quality before estimating the migration?
- How will you preserve account hierarchies, record ownership, activity history and custom-object relationships?
- How many full test cycles are included, and what reconciliation evidence will we receive?
- Which workflows and integrations will be redesigned rather than copied?
- What is the cutover and rollback approach, and who has go/no-go authority?
- What support is included after launch, and how are migration defects distinguished from new-scope requests?
Final recommendation
Choose a CRM migration approach based on business continuity and data trust, not on how quickly records can be imported. The strongest plan makes data ownership explicit, tests relationships and workflows, reconciles outcomes with business users and treats adoption as part of the migration. For a broader implementation perspective, see our guides to ERP implementation challenges and ERP data migration planning.
Author: Micah Phillips
