Five lessons from migrating CRM data that went wrong first

Every CRM implementation has a migration, and it is almost always scheduled as though it were a data transfer. It is not. It is a reconciliation of several teams' disagreements about what a customer is, and it surfaces late.

Duplicates are a process problem

Deduplication tools find records that look alike. They cannot tell you whether two records that look alike *are* the same customer — a franchise group, a parent company, a person who changed employer. Decide the rule with the business before writing any matching logic, and expect that conversation to take longer than the code.

Run the migration early, repeatedly

The first full-volume run should happen months before go-live, into a sandbox nobody minds breaking. It will fail. That is the point: every subsequent run is cheaper, and the last one is boring.

Do not migrate everything

The instinct is to bring across all history. Most of it will never be read again, and it drags quality metrics down. Agree an active window, archive the rest somewhere retrievable, and start clean.

Validate against behaviour, not row counts

Matching totals prove nothing. Pick twenty real workflows — the quarterly report, the renewal list, the escalation queue — and confirm each produces the same answer before and after.

Name an owner for the data

Not a project role. Someone in the business who decides what a valid record looks like, and stays after launch. Without them, quality decays back to where it started within a year.