CRM Migration Checklist: 12 Steps for a Safe Move (2026)

A CRM migration checklist should protect more than contact rows. A safe move preserves the links between companies, contacts, deals, owners, activities, consent records, and reports, then proves that the new CRM can run the business before the old one is retired.

The practical rule is simple: do not approve the cutover because an import finished. Approve it only when record counts reconcile, active deals have the right owners and associations, essential workflows pass testing, and the reports used by leadership return expected numbers.

If the destination CRM is not selected yet, pause here and complete the CRM requirements checklist. If the product is selected but the whole rollout still needs planning, use the CRM implementation checklist. This guide is narrower: it covers moving working data and business context from an old CRM into a new one.

CRM migration checklist: quick version

Use these 12 steps as the agenda for the migration project:

1. Confirm why the CRM is changing and what success means.
2. Assign one migration owner and named data owners.
3. Inventory every object, field, workflow, integration, and report.
4. Decide what will migrate, what will be archived, and what will be deleted.
5. Export and back up the source CRM before changing data.
6. Clean duplicates, stale records, owners, formats, and consent status.
7. Map users, objects, fields, stages, relationships, and historical activities.
8. Choose the migration method and prepare the target CRM.
9. Run a representative test migration.
10. Test workflows, integrations, permissions, and reporting.
11. Execute a controlled cutover with a freeze, final delta, and rollback plan.
12. Reconcile the new CRM and stabilize it through day 30.

CRM migration, implementation, and integration are different

These projects overlap, but they are not interchangeable:

A migration can sit inside a larger implementation. An integration can also support a phased migration by keeping selected records synchronized during transition. The distinction matters because a one-time CSV import will not keep two databases current, and a data-sync tool will not redesign your pipeline, permissions, or reports.

If the move affects the wider revenue stack, map those dependencies with the B2B tech stack guide. If email campaigns, consent, or marketing automations are moving too, run the email marketing migration checklist as a separate workstream.

CRM migration checklist before touching data

The first six steps decide whether the later import is controlled or improvised.

1. Confirm the reason and success criteria

Write the reason for switching in one sentence. Valid reasons include missing pipeline or reporting capabilities, fragmented sales and marketing data, excessive administration costs, poor adoption, or a business consolidation that requires one customer record.

Then define measurable pass conditions. A migration goal such as “move to HubSpot” says nothing about whether the project worked. Better criteria include:

• Every active opportunity has an owner, company, primary contact, stage, amount, and next step.
• Record counts match the approved source totals minus documented exclusions.
• Core pipeline and revenue reports reconcile to the old CRM.
• Opt-out and consent records are preserved before marketing sends resume.
• Sales can complete its five most common tasks without the old CRM.

Use the CRM total cost of ownership model if the expected savings depend on lower administration, integration, or migration costs. Confirm those assumptions before signing a contract.

2. Assign owners and decision rights

Name one migration owner who can approve scope, mapping, test results, and cutover. Depending on the company, this may be a CRM administrator, RevOps lead, Sales Ops lead, or project manager.

Also assign data owners for sales, marketing, customer success, support, finance, and any other team represented in the CRM. A data owner decides what a field means, whether a record should move, and how the target system should handle exceptions. Document who can change mappings, approve exclusions, pause integrations, approve cutover, and trigger rollback.

Without those decisions, migration meetings become debates about field names while the launch date keeps moving.

3. Inventory the source CRM

Do not start with the contact export. Inventory users, owners, leads, contacts, companies, deals, tickets, products, quotes, custom objects, activities, attachments, pipelines, forms, workflows, integrations, reports, permissions, teams, and territories. Include every linking object or matching rule that connects them.

HubSpot's import documentation separates objects, records, activities, properties, and associations. That is a useful planning model even when HubSpot is not the destination. A contact can import correctly while its company, deal, activity history, and owner links fail.

Support data deserves its own review. If tickets or cases are part of the customer record, use the CRM ticketing system guide to decide what belongs in the destination CRM and what should remain in a help desk.

4. Decide what to migrate and archive

Moving everything is rarely the safest choice. Put each dataset into one of four groups:

Active opportunities, current customers, open tickets, valid contacts, consent records, and recent activity history usually deserve priority. Old test records, unused custom fields, abandoned automations, and duplicate exports usually do not.

Do not delete source data casually. Confirm retention requirements and create a readable archive before removing anything. The point is to keep the new CRM useful, not to erase history without a policy.

5. Export and back up the source

Create a complete source backup before cleanup or transformation. Keep the original export unchanged, then do cleanup in working copies.

Save raw object exports, activities, attachments, field definitions, user lists, workflow documentation, integration details, report definitions, and source counts by object and status. Record when the export ran and which account created it.

Store the backup somewhere independent of both CRMs. Confirm that the files open, columns are present, attachments are accessible, and record counts match the source. An export that cannot be restored or interpreted is not a useful backup.

6. Clean data before migration

Clean the source working copy before mapping it. Fix duplicate people and companies, missing identifiers, former owners, inconsistent formats, stale stages, invalid dropdown values, unclear consent status, mixed-purpose fields, and records that violate target requirements.

Set a matching hierarchy for each object. Contacts might match first on a stable source ID, then email. Companies might use source ID, domain, then an approved name-and-address rule. Deals need a source ID or another key that does not collapse separate opportunities with similar names.

Pipedrive's spreadsheet import guide shows why preflight work matters: item types have mandatory fields, additional identifiers reduce duplicates, and skipped rows need correction after import. The exact rules differ by CRM, so build the cleanup process around the destination's requirements.

CRM data migration checklist for mapping relationships

Field mapping is only one layer. The migration plan must preserve who owns a record, how records connect, and what historical context users need.

7. Map users, objects, fields, and relationships

Create a mapping workbook with one row per source field. Include:

Map users before records so active deals and accounts can receive valid owners. Decide how records owned by former employees will be reassigned.

Map pipeline stages by meaning, not by similar labels. “Qualified” in the old CRM may not equal “Qualified” in the new one. For every stage, record the entry rule, exit rule, probability, required fields, and reporting treatment.

Then map relationships explicitly:

• contact to company
• deal to company and buying contacts
• activity to contact, company, deal, or ticket
• ticket to customer and owner
• product or line item to deal
• parent company to subsidiary
• custom object to its related records

Zoho CRM's migration documentation lists users, contacts, deals, campaigns, notes, activities, attachments, custom modules, and linking modules as distinct migration concerns. That breadth is a reminder to test the data graph, not only individual rows.

If Gmail logging is important, verify what historical email can move and how future messages will sync. The CRM Gmail integration checklist covers logging, permissions, calendars, shared inboxes, and reporting.

8. Choose the migration method and prepare the target

Choose the method by complexity:

• Native spreadsheet import: suitable for small, clean datasets with standard objects and limited history.
• Vendor migration tool: useful when the source CRM is explicitly supported and the tool can preserve required objects and relationships.
• Integration or temporary sync: useful for phased moves, but it needs clear ownership and conflict rules.
• API or ETL migration: better for large datasets, custom objects, transformations, repeated test runs, and detailed logs.
• Specialist partner: appropriate for complex operations, regulated data, many integrations, or limited internal experience.

Before importing, configure the target users, permissions, currencies, fields, pipelines, stages, custom objects, association types, and required dropdown values. Disable notifications and workflows that should not fire during test imports.

Do not build every new automation before the data model is proven. Start with enough configuration to test the records and relationships, then layer workflow logic onto stable data.

Test the CRM migration before cutover

The test should resemble production closely enough to expose real failures.

9. Run a representative test migration

Do not test only 20 clean contacts. Include a representative sample from every object and edge case:

• companies with several contacts and deals
• contacts without email addresses
• duplicate candidates
• former owners
• open and closed opportunities
• multiple currencies and date formats
• notes, calls, meetings, and attachments
• opt-outs and different consent states
• custom objects and parent-child relationships
• records that should fail validation

Run the same migration sequence planned for cutover. Record the time required, import order, errors, skipped rows, manual fixes, and re-run steps.

The test passes only when the team can explain every exclusion and error. Spot-check records inside the CRM rather than relying only on import totals.

10. Test workflows, integrations, permissions, and reports

Imported records can look correct while the system around them is broken. Test assignment, status changes, tasks, forms, email and calendar sync, marketing and support integrations, duplicate prevention, role-based access, pipeline reports, forecasts, and weekly dashboards.

Create a migration acceptance table before testing:

If marketing automation is being rebuilt, use the marketing automation requirements checklist to test triggers, suppression, scoring, handoff, reporting, and data rules.

CRM migration plan for cutover and rollback

Cutover is where records created during the move can disappear. Control the transition rather than asking both systems to stay correct by habit.

11. Freeze, migrate the final delta, and cut over

Publish the cutover schedule to every user and connected-system owner. Include:

1. Stop configuration changes in both CRMs.
2. Take a final backup and record source totals.
3. Make the old CRM read-only, or define a short data-entry freeze.
4. Export records created or changed since the last migration run.
5. Run the final migration in the tested order.
6. Review import logs and fix blocking errors.
7. Run the acceptance checks.
8. Approve go-live or trigger rollback.
9. Re-enable integrations, notifications, and workflows in a controlled order.
10. Tell users which system is now authoritative.

Write rollback criteria before cutover. Examples include missing active opportunities, incorrect owner assignments at scale, broken consent status, failed core integrations, or pipeline totals outside the agreed tolerance.

Keep the old CRM read-only until reconciliation is complete. Do not ask users to update both systems for weeks without a defined sync and conflict policy. That creates two incomplete sources of truth.

12. Reconcile and stabilize through day 30

Run daily checks during the first week, then lighter checks through day 30. Track:

• source and target counts by object
• skipped and failed records
• duplicate creation
• owner and association errors
• pipeline totals by stage and owner
• workflow failures
• integration sync errors
• dashboard differences
• active users and records updated
• user-reported missing history or access

Fix root causes before re-importing failed rows. If a dropdown mismatch caused 500 failures, correct the mapping once instead of editing 500 records manually.

Close the migration only after data owners sign off, core reports reconcile, users have stopped relying on the old CRM, and the archive is documented. Then move ongoing adoption, governance, and optimization into the normal CRM operating process.

Common CRM migration mistakes

Treating the migration as a contact import. Contacts without companies, deals, activities, and owners lose the context sales needs.

Migrating every historical field. Old clutter becomes new clutter and makes layouts, training, and reporting harder.

Mapping labels instead of meaning. Similar stage names can represent different entry rules, probabilities, and reports.

Testing only clean records. A perfect sample hides duplicate, owner, currency, attachment, and relationship problems. Keep workflows disabled until test data has been reviewed.

Skipping the final delta. Records created after the first export can fall into the gap between systems.

Assuming rollback means clicking Undo. Keep a source backup, import logs, mapping files, and a defined decision point even when the destination offers an import-revert feature. Continue reconciliation and report validation after go-live.

Actionable takeaways

• Treat objects, relationships, ownership, history, and reporting as separate migration tests.
• Define pass conditions and rollback criteria before the final import.
• Keep the raw source backup unchanged and perform cleanup in working copies.
• Migrate users and configure target fields before importing owned records.
• Test representative edge cases, not only clean contacts.
• Use a freeze and final delta so records created during cutover are not lost.
• Reconcile counts, pipeline value, consent, associations, workflows, and reports through day 30.

Frequently Asked Questions

What is a CRM migration checklist?

A CRM migration checklist is a controlled plan for moving records, relationships, activities, owners, workflows, integrations, and reporting context from an old CRM into a new one. It defines the work, owners, validation rules, cutover sequence, and rollback criteria.

How long does CRM migration take?

A clean spreadsheet with basic contacts and deals may take days. A CRM-to-CRM move with custom objects, activities, attachments, integrations, automations, and reporting usually needs several test cycles and a longer project window. Estimate from the number of objects, transformations, dependencies, and acceptance tests, not only the row count.

What CRM data should be migrated?

Prioritize active opportunities, current customers, valid contacts, required account history, consent records, open tickets, and the data needed for daily workflows or reporting. Archive older data that must remain retrievable but does not need to sit in the live CRM.

Should CRM data be cleaned before or after migration?

Clean duplicates, formats, owners, stale stages, invalid values, and consent problems before migration. Use post-migration cleanup for issues discovered during validation, not as the main data-quality plan.

How do you test a CRM migration?

Run a representative import containing every object and major edge case. Then reconcile counts, inspect associations, test owners and permissions, run workflows and integrations, and compare priority reports with approved source totals.

Can CRM migration be rolled back?

Sometimes a platform can revert newly created records, but updates, merged data, and connected workflows may not reverse cleanly. Keep a complete source backup, import logs, mapping files, a read-only old CRM, and written rollback criteria until the migration is accepted.

What is the difference between CRM migration and CRM implementation?

Migration moves data and context from the old system. Implementation includes migration plus target configuration, workflow design, integrations, permissions, training, adoption, and governance. A CRM switch often requires both.

Next steps

Choose the destination before applying this CRM migration checklist. Start with the comparison that matches the operating decision:

• CRM adoption versus enterprise architecture: HubSpot vs Salesforce
• Focused sales pipeline versus connected marketing and service: Pipedrive vs HubSpot
• Budget customization versus simpler all-in-one adoption: Zoho CRM vs HubSpot
• Marketing automation versus a broader CRM-led platform: ActiveCampaign vs HubSpot

After the destination is selected, use the CRM implementation checklist to plan configuration, training, launch ownership, and the first 30-day adoption review around the migration.