The risk in a CRM migration isn’t the new system. It’s the twelve years of relationship history, giving records, notes and attachments that make the system worth having at all.
Migrations go wrong in predictable ways: custom fields with no equivalent on the other side, relationships that flatten out, historical activity dropped because it was “just notes”, duplicates multiplied by a partial re-run, and a go-live where the team quietly keeps using the old system because they can’t find anything.
So we run it as a proper project.
- Map the data model — every object, field and relationship, with a decision recorded for each: migrate, transform, archive or drop. The drops are explicit and signed off, not accidental.
- Clean on the way through. A migration is the best chance you’ll ever get to dedupe and standardise. We do it before load, not after.
- Trial load into a sandbox, then reconcile counts and spot-check records against the source. Fix, repeat.
- Rebuild the working layer — reports, dashboards, automations and integrations — so day one in the new system is usable, not a blank slate.
- Staged cutover with the old system kept read-only for an agreed period, so nothing is unrecoverable.
- Train before go-live, not after.
We keep a full reconciliation record, so if anyone asks in six months whether a record made it across, the answer is evidence rather than a shrug.