Prove a CRM migration before you cut over

Define what is moving

The sales team in this example is moving accounts, contacts and open opportunities between CRMs. Its earlier import treated the CSV as the specification. Unused fields, inactive owners and deleted accounts became decisions made during loading, when they were hardest to review.

Create a migration inventory first. Mark each object and field as migrate, transform, archive or exclude. Record the business owner who approved the choice. Excluding a record deliberately and failing to import it are different outcomes.

Keep an immutable source identifier on the target or in a crosswalk. A company name can change; the migration relationship should survive that change.

One account can produce several contacts, not several copies

Load parent records before dependents. For each source account ID, retain its target account ID and load status. A contact whose parent hasn't loaded stays in a rejection ledger with the reason and repair owner. Don't create a placeholder company silently.

Owner mappings need the same treatment. Map a departed employee to an approved successor or an explicit holding owner. Unknown picklist values should be reviewed; defaulting every unknown opportunity to an open stage can distort pipeline reporting.

Normalize types deliberately. Preserve currency alongside amounts, distinguish date-only fields from timestamps and document how blanks differ from zero. A transformation rule belongs in the mapping sheet so the business can review it.

Build the complete field-mapping workbook ↗

Reconcile at more than one level

Record counts are the first control, not the only control. Reconcile eligible source records to loaded, rejected and deliberately deferred records. Then compare relationships, required-field coverage and business totals using the same inclusion rules on both sides.

For open opportunities, compare amounts by currency and stage. Do not add unlike currencies into a convenient total. Review a sample of transformed records, including special characters, long notes and inactive owners. Verify what users can see, not just what an administrator imported.

If a deduplication policy merges two source records into one target, keep both source IDs in the crosswalk and explain the count difference. A lower target count is acceptable only when the disposition is known.

The last change window is a separate migration

Agree how writes behave during cutover. Either pause writes in the source for an agreed window or capture and reconcile a bounded delta. Record the export watermark and the final accepted change. An unbounded last-minute export makes the baseline impossible to reproduce.

Keep the source readable and define who can authorize rollback. Reverting is straightforward only while new target writes can be accounted for. Once users edit both systems, restoration requires a reconciliation plan, not a switch.

The go/no-go review should include sales operations, the data owner and someone who will use the target for ordinary work. Test creating a lead, assigning an owner and producing the key pipeline report.

Keep the source export, mapping version and reconciliation output together under restricted access. The migration owner sets a retention date after acceptance; keeping a staging copy forever should not be the accidental default.

A useful stopping rule

Don't cut over with unexplained rejected rows or missing parent relationships in the agreed scope. An approved exclusion can remain outside the migration, but it needs a durable reason and an owner. The target system should open with a known backlog rather than a hidden loss.