Migration and data portability
Reconcile a CRM migration before switching the team over
Check record identities, relationships, totals and attachments with a bounded migration rehearsal.
Freeze a comparison point
Choose a cut-off time and record exactly what the migration includes. In this fictional rehearsal, the source contains three contacts, two companies, two open deals and one attachment. Save a read-only source export and its format description. Record how changes made after the cut-off will be captured. Comparing a Monday export with a live Wednesday system produces differences that no amount of recounting will explain.
Keep the identity mapping
Use source identifiers as the reconciliation key. If the new CRM assigns fresh identifiers, keep a mapping table with the source type, source ID, destination ID and import batch. Do not join contacts by display name: two people can share a name, and a company can change its trading name. In the rehearsal, C-101 and C-102 both belong to company B-10. Their destination records must still point to the same destination company after import.
Count and inspect different things
Counts detect missing records, but they do not establish correct relationships. Check each object type, duplicate identifiers, required fields, parent links and attachment availability. The fictional import reports three contacts and two deals, matching the source. A relationship check still fails: deal D-02 points to B-10 instead of B-20. Record this as a failed rehearsal even though the totals match. Fix the mapping and repeat the same checks before accepting the batch.
Check money, dates and text explicitly
For amounts, record the currency, precision and whether each field includes tax; do not compare unrelated totals. For dates, distinguish a calendar date from a timestamp with a time zone. Include accented names, an empty optional field and a closed record in the trial. Open a retained attachment and compare its checksum with the source file. A link that still points to the old provider is not a migrated attachment.
Resolve every difference
Use a discrepancy log with the source ID, expected value, actual value, cause, owner and resolution. An intentionally excluded duplicate needs an approved exclusion entry. It must not disappear into an unexplained shortfall. Preserve the first failed result alongside the corrected result so another person can understand the change. The downloadable example on this page contains synthetic records only; it demonstrates the checks, not a completed customer migration.
Define the switch and rollback
Before the final run, name the person who authorises access to the new CRM. Agree which failures stop the switch and how work performed during the transition will be recorded. Keep the old records available under the agreed access and retention arrangements. Reverting an application does not merge new transactions automatically: write down how changes in the new system would be reconciled before returning users to the old one.
Download: Synthetic migration records and a failed relationship example (JSON, fictional data)