CRM Data Migration Checklist: Phase by Phase

CRM migrations rarely fail because of the tool used to move the data. They fail because of something nobody checked: notes that were never exported, owners who no longer exist in the new system, a picklist value that does not map, or attachments left behind in the old platform. A CRM data migration checklist turns those lessons into steps you tick off before, during and after the move. This guide gives a practical checklist organised by phase, explains why each item matters and shows how to reconcile the results, with a worked example of a mid-sized migration.

How to use this CRM data migration checklist

Treat the checklist as a working document, not a formality. Give each item an owner and a date, record the evidence that it is done, such as a file, a count or a sign-off, and keep it alongside the migration plan. Items that do not apply to your migration can be marked as such, but should not be deleted, so reviewers can see they were considered.

Phase 1: Before you export anything

CheckWhy it mattersList every object in scope: leads, contacts, accounts, deals, activities, notes, attachments, custom objectsForgotten objects are the most common cause of lost historyRecord counts per object in the old systemThe baseline for reconciliation laterDecide what not to migrate, such as leads untouched for yearsReduces volume and clutterMap every field, including type, length and picklist valuesMismatched types cause rejected recordsMap users and owners, including people who have leftRecords need a valid owner in the new CRMAgree on duplicate rules and clean duplicates at sourceMigrating duplicates multiplies the problemIdentify external IDs to keep relationships intactContacts must stay linked to the right accountsConfirm how attachments and emails will moveOften handled by a separate processFreeze changes to the old system's structurePrevents the mapping going out of date

Field mapping deserves the most time. List every field in the old system next to its destination, with a note on transformations: a free-text country field mapped to a picklist, two name fields combined, or a currency converted. Fields with no destination should be a deliberate decision, not an accident.

Phase 2: Trial migrations

Run at least one full trial into a sandbox before the real move. A trial shows how long the migration takes, which records are rejected and why, and whether relationships survive.

• Import in dependency order: users, then accounts, then contacts, then deals, then activities and notes
• Keep the old system's ID in a field on every migrated record
• Log every rejected record with its error and fix the cause, not just the record
• Compare counts per object between source and sandbox
• Ask two or three users to check records they know well
• Time the full run, so the cutover window is realistic

Zoho CRM's duplicate check features help catch duplicates that slipped through cleaning, but they work best as a safety net rather than a substitute for cleaning at source.

Phase 3: Cutover

CheckWhy it mattersAnnounce the cutover window and freeze data entry in the old systemPrevents changes that would be lostTake a final export and keep a read-only copy of the old systemNeeded for audits and disputesRun the migration in the same order as the trialRepeats a tested processMigrate changes made since the last trial, if using a delta approachShortens the freezeReconcile counts per object before opening the new CRMCatches gaps while there is time to fix themSwitch integrations and web forms to the new CRMNew leads must arrive in the right placeDisable automations during the load, then re-enable themPrevents thousands of emails or tasks firing

That last item catches many teams. Workflows, assignment rules and email alerts that fire on record creation will treat every migrated record as new. Turn them off during the load and back on afterwards.

Phase 4: After go-live

• Spot-check records by object with the people who use them
• Confirm reports and dashboards match the old system's figures for a closed period
• Check that activity and note histories appear on the right records
• Keep the old system read-only for an agreed period
• Track issues raised by users in the first two weeks and fix patterns, not just individual records
• Remove temporary fields and import mappings once everything is confirmed

Worked example: reconciling a migration

Suppose a services company is moving from another CRM to Zoho CRM. It has 14,200 contacts, 3,900 accounts, 6,100 deals, 41,000 activities and 22,000 notes. After the second trial migration into a sandbox, the reconciliation sheet looks like this:

ObjectSource countExcluded by ruleExpectedMigratedDifferenceCauseAccounts3,900120 (duplicates merged)3,7803,7800Contacts14,200600 (inactive, no activity in 5 years)13,60013,54060Invalid email formatDeals6,10006,1006,08515Owner not mappedActivities41,0002,000 (linked to excluded contacts)39,00039,0000Notes22,000022,00020,9001,100Notes on closed deals not exported

Each difference has a cause, and each cause has a fix. The 60 contacts need email clean-up at source. The 15 deals belong to a former employee who was missing from the user map. The 1,100 notes reveal an export filter that skipped closed deals, exactly the kind of gap that would have gone unnoticed without a count per object. After fixing all three, the third trial reconciles to zero, and the team schedules the cutover.

The "Excluded by rule" column matters as much as the differences. It documents what was left behind on purpose, so nobody later mistakes a deliberate exclusion for a lost record.

Common migration mistakes

• Migrating everything because deciding what to leave behind feels risky
• Skipping trial runs to save time, then discovering problems during cutover
• Losing relationships because old IDs were not kept
• Leaving automations switched on during the load
• Reconciling only totals rather than counts per object
• Switching off the old system before users have confirmed their data

A migration from Salesforce has its own quirks; our guide to Salesforce to Zoho CRM migration covers how to keep record history intact. Cleaning data before the move saves effort afterwards, and our guide to CRM data hygiene explains how to find and merge duplicates.

Frequently Asked Questions

What should a CRM data migration checklist include?

Scope and record counts, field and user mapping, duplicate rules, trial migrations, a cutover plan with automations paused, reconciliation per object and post-go-live checks with users.

How many trial migrations should we run?

At least one full trial into a sandbox, and another after fixing the issues it reveals. Repeat until counts reconcile and users are satisfied with spot checks.

How do we know nothing was lost?

Reconcile record counts per object between the source and the new CRM, account for every record excluded by rule and have users check records they know well.

Should automations be turned off during migration?

Yes. Workflows, assignment rules and alerts can treat migrated records as new and fire emails or tasks. Pause them during the load and re-enable them afterwards.

Plan your migration with us

We plan and run CRM migrations with field mapping, trial runs, reconciliation and a controlled cutover. See our Zoho CRM implementation services, or talk to us about your migration checklist.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.