CRM migration checklist

What you get

• A phase-by-phase checklist from scoping through hypercare
• An object mapping table with load order, record counts, and transformation rules
• A validation sheet that reconciles source and target counts and totals per object
• A cutover runbook and a written rollback trigger, agreed before go-live
• A hypercare plan for the first two weeks after launch

Who it's for

• •RevOps and CRM admins moving between Salesforce, HubSpot, Dynamics, or another CRM
• •Project leads who need a phase plan and sign-off criteria for a migration
• •Sales ops teams consolidating multiple CRM instances after an acquisition

What's inside

1. 1

   Phase 1: Scope and decisions

   7-point checklist

2. 2

   Object mapping

   7 columns, 5 worked example rows

3. 3

   Phase 2: Field mapping and data cleanup

   7-point checklist

4. 4

   Phase 3: Test loads

   6-point checklist

5. 5

   Validation counts

   8 columns, 3 worked example rows

6. 6

   Phase 4: Cutover, rollback, and hypercare

   8-point checklist

7. 7

   Where migrations actually go wrong

   Guidance notes

The preview shows part of section 1. The full template has all 7 sections (6 not previewed here), with blank rows ready to fill in. Download the full template

How to use it

1. 1

   Decide what not to migrate

   The default should be to leave data behind. Closed-lost opportunities older than two years, leads with no activity in eighteen months, and fields under 5% fill rate rarely earn their place. Archive them to a file you can query and start the new system clean.

2. 2

   Map fields by meaning, not by name

   A field called 'Type' in the old CRM may hold three different concepts depending on who created the record. For every mapped field, write the definition and check a sample of 50 records against it before you trust the mapping.

3. 3

   Load in dependency order and keep legacy IDs

   Users, then accounts, then contacts, then opportunities, then line items and activities. Store the source system ID on every record in a dedicated external ID field. It is the only reliable way to link children to parents and to fix a bad load without starting over.

4. 4

   Validate with counts and sums, not spot checks

   For each object, compare record counts and the sum of a key numeric field (amount, ARR) between source and target. A migration that 'looks right' in ten records can be missing four thousand. Sign-off happens when the numbers reconcile.

5. 5

   Write the rollback trigger before cutover

   Agree in advance what failure looks like (for example, open pipeline totals off by more than 1%, or reps unable to log activity for four hours) and who can call it. Nobody makes a clear-headed rollback decision at 11pm on cutover night.

Frequently asked questions