CRM migration: what breaks when data moves but the process does not
A CRM migration that copies records but not pipeline stages, ownership, and history loses what sales relies on. A checklist for what to carry over on purpose.
A CRM migration gets scoped as a data export and a data import, and that scoping is where most of the damage happens. The records move. What does not move automatically is the meaning attached to them: why a deal sat in a stage for six weeks, who actually owns a territory when two reps both touched an account, and which of the forty custom fields anyone still reads.
None of that shows up in a row count. It shows up three months later, in a forecast that does not match what the sales floor already knows.
What a straight copy actually loses
Contacts and companies migrate cleanly almost every time. Everything downstream of them is where a straight copy stops being safe.
| Data | Copies cleanly | Needs a decision first |
|---|---|---|
| Contacts and companies | Yes | Dedup rules, since two systems rarely agree on "same account" |
| Deal and opportunity records | Mostly | A stage map between the old pipeline and the new one, written down |
| Activity history | Rarely in full | Compress to a timeline, or accept the loss and say so |
| Custom fields | No | Which ones a rep still reads before a call |
| Reports and dashboards | No | Rebuilt against the new schema, never copied |
The stage map is the one item on that list that people skip because it looks obvious. It is not. "Negotiation" in a five-stage pipeline and "Negotiation" in an eight-stage pipeline are not the same stage, and mapping them 1:1 silently changes what every historical conversion-rate report means.
The cutover that does not cost you a quarter of pipeline
Two approaches, and the wrong one depends on how much pipeline is in flight, not on preference.
A big-bang cutover works when the pipeline is small enough that a rep can re-enter anything missed in a day. Past a few hundred open deals, it does not: the freeze window needed to reconcile data grows past what sales will tolerate, and reps start keeping a shadow spreadsheet the moment the freeze starts, which defeats the migration before it finishes.
A parallel run, where both systems stay live and the new one becomes the system of record only after a defined verification period, costs more calendar time but does not force a freeze. It is the same reasoning behind a strangler-fig migration for a legacy system: replace load gradually, keep the old path working until the new one is proven, and never bet the business on a single cutover weekend.
Ownership disputes are a migration problem, not a CRM problem
A territory or account-ownership disagreement that already existed in the old system does not resolve itself by moving to a new one; it just gets re-encoded, usually incorrectly, because whoever runs the migration has to pick an owner for every ambiguous record and rarely has the context to pick right. Settle ownership rules before the migration, not during it, the same discipline that applies when integrating around a legacy ERP without touching its data model.
We run CRM migrations as part of our CRM & Revenue Operations practice, scoped with the same discipline as any other modernization engagement: an inventory before a single record moves, and a written stage map that sales signs off on. How we protect data in flight, including under a signed BAA when health data is involved, is in our security practices.
Check your own case
Where does your team stand on this?
The article describes the pattern. These take your answers and tell you which part applies to you — no signup to see the result.