Migrations rarely fail on the data. They fail on everything that was quietly running on top of the old system.
Step 1: inventory the dependencies
Before touching anything, list every integration, automation, report, webhook, saved view and export that touches the CRM, with an owner beside each.
This list is always longer than expected, and the surprises are consistent: an automation that emails customers, a report someone builds the board deck from, an integration finance uses at month end, and a webhook created two years ago by somebody who has left.
Anything without an owner is either deleted now or adopted now. Not carried across in the hope it still matters.
Step 2: agree the mapping in writing
Fields and stages, old to new, decided before anything moves.
This is where the arguments live, and they are far cheaper before the migration than during it. Two teams that define a stage differently will discover it while looking at a broken pipeline report otherwise.
Use the mapping as the opportunity to delete. If you carry the mess across, you paid for a move and kept the problem.
Step 3: history first, process second
Get records in and readable before recreating any logic. A migration with the data in place and no automations is recoverable. One with automations running on incomplete data creates errors you then have to find.
Step 4: run both in parallel, with one source of truth
For a defined period covering at least one month end and one reporting cycle. Designate which system is authoritative during that window and say so repeatedly, because two sources of truth means neither is trusted.
Open ended parallel running is worse than none.
Step 5: cut over one team at a time
The first team is the pilot. Expect to find three things nobody documented, fix them, then move the second team. Cutting everyone over at once means debugging several unrelated problems while every team is blocked.
Step 6: keep the old system readable for a quarter
Read only, for the questions that arrive later: what did this record look like before, what did we promise this customer, why does this number differ from last year.
The dependency that breaks the most migrations
Reporting. Not because it is hard to rebuild, but because everyone assumes someone else understands how the current number is produced.
Rebuild the three or four reports leadership actually uses first, verify them against the old system while both are live, and only then move the rest.
When not to migrate at all
When the real problem is that the current system is badly configured rather than genuinely unsuitable.
A migration carries a configuration problem to a new platform at considerable cost, and the second implementation usually inherits the same habits that produced the first one. Fixing the configuration is cheaper, faster and less disruptive, and if it fails you have lost weeks instead of a quarter.