# CRM Migration Checklist

**SoftwareGlimpse** · Updated 15 Aug 2026  
**Type:** MIGRATION_TEMPLATE · **Stage:** IMPLEMENT  
**JTBD:** Move CRM data safely with mapping, dry-run, cutover, and rollback gates.

> Gate the data move: inventory, mapping, dry run, cutover, rollback. Use this for the records themselves — what moves, what it becomes, what a rehearsal proved, and what would make you stop the cutover and go back.

## How to use

1. **Inventory the sources** — List every system holding CRM records, with volumes, history depth, and an owner.
2. **Map fields and values** — Source to target per object, plus stage, forecast, and owner translations signed by the business.
3. **Cleanse and dedupe** — Set match keys, survivorship, defaults for required fields, and the exclusion list.
4. **Dry run and fix** — Load into staging, time it, fix the defects, and have owners check named records.
5. **Freeze and cut over** — Follow the runbook: freeze writes, extract, load, smoke, then decide whether to open.
6. **Validate and watch** — Reconcile pipeline totals, staff a merge queue, and keep rollback available.

## Result key

| Result | Meaning |
| --- | --- |
| Pass | Verified with evidence |
| Partial | Met with limits or a workaround |
| Fail | Does not meet a required check |
| Not tested | No evidence yet — do not invent a Pass |

## Evidence that counts

- A staging load report with error counts and timings
- Business-owner sign-off on named sample records
- Pipeline totals reconciled against the source within an agreed tolerance
- A rollback plan with named triggers and a decision owner

## Evidence that does not count

- Matching row counts on their own
- A mapping workbook nobody outside the data team reviewed
- “The import tool handles that”
- A cutover plan that has never been rehearsed

## Checklist

### 1. Inventory gate

You cannot migrate what nobody has admitted exists.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1.1 | Every source system listed with an owner | Shadow spreadsheets appear after cutover as “missing data” with no route back. | Must-have | List the legacy CRM, spreadsheets, marketing lists, and support tools holding accounts, contacts, or deals, each with a named owner. | | | |
| 1.2 | Objects in and out of scope written down | Unstated scope turns into an argument during the freeze window. | Must-have | Record a decision for accounts, contacts, leads, deals, activities, notes, files, and custom objects: migrate, archive, or leave behind. | | | |
| 1.3 | Open pipeline deals scoped explicitly | Open deals are the first records the business checks and the most expensive to get wrong. | Must-have | Define which open opportunities must arrive with stage, amount, owner, and next step intact, and what happens to the rest. | | | |
| 1.4 | History depth decided | Activity and email history usually drives volume and effort more than contacts do. | Must-have | Agree how far back activities and emails must come across, and what stays in a read-only archive. | | | |
| 1.5 | Sensitive and regulated fields flagged | Some fields carry handling rules that a bulk export happily ignores. | Nice-to-have | Mark personal, financial, or contractual fields and record who approves how they move. | | | |

### 2. Mapping gate

Column names match easily; meanings do not. This is where migrations are won or lost.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 2.1 | Field mapping workbook complete and reviewed | Similar field names routinely hide different meanings and different types. | Must-have | Map source to target for each object with type, required flag, default, and transform, then have a second admin review it. | | | |
| 2.2 | Stage and forecast translations signed | A wrong stage map poisons every pipeline and forecast report from day one. | Must-have | Translate every legacy stage and forecast category to the new model, including the unknown case, and have sales leadership sign it. | | | |
| 2.3 | Owner mapping resolved, including leavers | Deals owned by inactive users become invisible work nobody chases. | Must-have | Map legacy owners to new seats and set an explicit rule for records whose owner has left the business. | | | |
| 2.4 | Account, contact, and deal relationships preserved | Records that arrive unlinked are often worse than records that did not arrive. | Must-have | Check parent accounts, primary contacts, and deal-contact links on a sample hierarchy after a staging load. | | | |
| 2.5 | Legacy record IDs stored on target records | Support questions and any re-migration both need a way back to the source record. | Nice-to-have | Add a legacy ID field on each migrated object and confirm it populates during the load. | | | |
| 2.6 | Lead and activity strategy decided | Leaving these open guarantees a scramble inside the freeze window. | Nice-to-have | Decide whether open leads convert before load or migrate as they are, and whether activities migrate, summarise, or stay archived. | | | |

### 3. Cleanse & duplicate gate

Decide who wins before load night, not while the clock is running.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 3.1 | Match keys and survivorship rules defined | Duplicates created at load are far harder to clean than duplicates prevented. | Must-have | Define which fields identify a duplicate and which record survives, then test the rules on known duplicate pairs. | | | |
| 3.2 | Related records follow the survivor | A merge that orphans deals or activities is not a clean merge. | Must-have | Merge a sample pair and confirm deals, activities, and notes remain reachable on the surviving record. | | | |
| 3.3 | Defaults set for required target fields | Loads either fail or fill with nonsense when the source lacks a field the target requires. | Must-have | Decide what happens when the source has no stage, amount, owner, or next step, and test each default on sample rows. | | | |
| 3.4 | Exclusion list agreed before extract | Junk migrated once tends to stay for the life of the system. | Nice-to-have | List test records, obsolete campaigns, and closed junk deals that will not move, and get the business owner to agree. | | | |

### 4. Dry-run gate

Rehearse until cutover night has no surprises left in it.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 4.1 | Staging matches the target configuration | A rehearsal against a different schema teaches you the wrong lesson. | Must-have | Confirm staging objects, fields, stages, and required rules match the build you will load into. | | | |
| 4.2 | One full dry run completed and timed | The cutover window is a number you measure, not a number you guess. | Must-have | Run the load end to end in staging and record duration per object alongside the error report. | | | |
| 4.3 | Dry-run defects closed or risk-accepted | A second run that repeats the same errors wastes the rehearsal. | Must-have | List each mapping and load defect with an owner, then close it or record an explicit risk acceptance. | | | |
| 4.4 | Business owners validate named records | Row counts can match perfectly while the records themselves are wrong. | Must-have | Have business owners open known accounts and open deals and confirm stage, amount, owner, next step, and linked contacts. | | | |
| 4.5 | Pipeline totals reconciled against the source | A forecast that moves after migration destroys trust in the new CRM immediately. | Must-have | Compare open pipeline and forecast totals against the source within an agreed tolerance and explain any variance. | | | |

### 5. Cutover & rollback gate

Run this in order. Freeze, smoke, and validation are the steps people skip and regret.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 5.1 | Freeze window agreed and communicated | Records written to the old system during extract are lost silently. | Must-have | State who stops writing where, from when, and for how long, and track acknowledgements from each team. | | | |
| 5.2 | Final backups and extracts secured | Rollback is only real if the previous state still exists and someone can reach it. | Must-have | Store the final source extracts in a known location and confirm someone other than the data lead can retrieve them. | | | |
| 5.3 | Cutover runbook followed step by step | Improvised load nights produce steps nobody can reproduce or reverse. | Must-have | Work through the runbook in order, logging start time, end time, and errors for each object. | | | |
| 5.4 | Smoke checks pass before users return | Opening on an unverified load turns a data problem into an adoption problem. | Must-have | Search a known account, open a migrated deal, move a stage, open the pipeline board, and confirm the email sync heartbeat. | | | |
| 5.5 | Rollback triggers and decision owner named | Mid-cutover is the worst possible time to work out who decides. | Must-have | Write the conditions that stop the migration and name the person who calls it, before load night begins. | | | |
| 5.6 | Duplicate and defect watch staffed after load | Migration problems surface as people start working, not at the moment of load. | Must-have | Run a merge queue and a defect intake for the first days after load, with named coverage and hours. | | | |

## Worked example

_Hypothetical dry-run scenario for teaching the artifact — not a SoftwareGlimpse case study._

**Requirement:** Every open deal arrives with the correct stage, amount, and owner after load.

| Scenario | Result | Note |
| --- | --- | --- |
| Dry run 1 | FAIL | Legacy stage names fell through to the default, so a large share of open deals landed in the first stage. |
| Dry run 2 | PASS | After a signed stage translation table, business owners matched a sample of known deals end to end. |

**Evidence:** Staging load reports plus business-owner checks on named accounts and open deals.

## FAQ

**What does this checklist deliberately leave out?**

Configuration and pilot gates belong in the CRM Implementation Checklist, and launch day belongs in the CRM Go-Live Checklist. Detailed source-to-target rows belong in a field mapping template. This checklist gates the move itself.

**Do we migrate all historical activity?**

Often not. Many teams migrate recent activities and leave older history in a read-only archive. Decide explicitly, because activity and email volume usually drives complexity more than contact counts do.

**How many dry runs do we need?**

At least one full rehearsal covering accounts, contacts, and deals. Add a second when volumes are large, the stage or owner maps are complex, or the first run revealed mapping defects. Timing the dry run is how you learn the real cutover window.

**What counts as validation beyond row counts?**

Business owners opening named accounts and open deals and confirming stage, amount, owner, next step, and linked contacts — plus a pipeline and forecast comparison against the source within an agreed tolerance, with variance explained.

**When is rollback the right call?**

When smoke checks fail, open pipeline data is wrong at scale, sync is down, or an operationally critical integration has failed — and the freeze window still allows returning to the source system. Write the triggers before cutover night, not during it.

**Who signs the mapping?**

The business owner for each dataset signs the field map, and sales leadership signs the stage and forecast translations. The data team owns the workbook, but it should never be the only party that has read it.

## Related journey

1. [CRM Implementation Checklist](https://softwareglimpse.com/resources/crm-implementation-checklist/)
2. **CRM Migration Checklist** (this resource)
3. [CRM Go-Live Checklist](https://softwareglimpse.com/resources/crm-go-live-checklist/)
4. [CRM Training Plan](https://softwareglimpse.com/resources/crm-training-plan/)

## Related tools

- [CRM Migration Planner](https://softwareglimpse.com/tools/crm-migration-planner/)
- [CRM Implementation Planner](https://softwareglimpse.com/tools/crm-implementation-planner/)
- [CRM Finder](https://softwareglimpse.com/tools/crm-finder/)

---

Source: https://softwareglimpse.com/resources/crm-migration-checklist/