- 0:00–0:06
Agree what moves • Separate operational records, archives and exclusions. • Controlled extract · time + filters + count • Operational records • History for consultation • Reviewed exclusions • Business + data owners approve each boundary • Keep original extract separate from cleaning copies
A controlled source extract records its time, filters and count. Three branches distinguish operational records, history retained for consultation, and reviewed exclusions. Business and data owners approve each boundary, and the original extract remains separate from copies used for cleaning. The animation is a proposed process, not a report of completed migration.
- 0:06–0:12
Preserve identity and links • Map fields, owners and related records. • S17 · source contact • T71 · target contact • S2 · source company • C20 · target company • Stable IDs + field meaning + owner state • Illustrative IDs; name or email is not assumed unique
Illustrative contact S17 is related to company S2 in the source. Stable identifier mappings connect them to target contact T71 and company C20; the target contact-company relationship is reconstructed and checked. Names and emails are not assumed unique. Field meaning, transformations, required or empty values, ownership and inactive users need explicit decisions.
- 0:12–0:18
Rehearse awkward cases • Include missing fields and suspected duplicates. • Reason + owner • Checked reimport • Missing required field / suspected duplicate pair • Isolated trial · emails, tasks, integrations controlled • Retry: update or duplicate?
Reviewed reason-and-owner and checked-reimport artwork accompanies missing required fields and a suspected duplicate pair. Cases enter an isolated rehearsal whose outgoing emails, tasks and integrations must be controlled. Corrections retain original source IDs. Before retrying, establish whether the product updates, duplicates or triggers another effect; successful and safe retry is not asserted.
- 0:18–0:24
Explain the totals • An explained difference is not automatic acceptance. • 108 direct • 8 → 4 merged • 4 unresolved • 120 = 108 + 8 + 4 • 112 = 108 + 4 + 0 • 116 source rows represented; 4 unresolved — no acceptance • Source rows • Target records
The exact hypothetical example separates 120 source rows into 108 direct rows, eight rows in four approved duplicate pairs, and four unresolved rows. Those branches yield 108, four and zero target records, giving 112 targets and representing 116 source rows. Four rows remain unresolved. Explaining the counts does not accept the migration: values, relationships, permissions and nominated-user tasks still require evidence.
- 0:24–0:30
Decide the change window • Plan final changes, validation and recovery. • Extract at T0 • Final validation • New records since T0 • User switch · still pending • Recovery must account for work after the extract • After successful rehearsal; four unresolved rows remain open
Only after a successful rehearsal should the final change window be agreed. A new-record token from after extract time T0 moves toward final validation, using a supported freeze or incremental process. The user-switch gate stays pending in this example because unresolved records and acceptance checks are open. Recovery must account for intervening work; restoring a backup can lose it, and simultaneous work in both systems creates reconciliation risks.
A silent 30-second explanation in five six-second beats. A source ledger accounts separately for imported records, approved merges and unresolved exceptions.
Read the article: CRM Data Migration Checklist: Reconcile Before You Switch