What Actually Breaks When You Migrate CRMs

A services firm moved off a CRM they had outgrown. The export ran clean, every contact and company landed in the new system, and the team declared the migration done on a Friday. The following month nobody could work out why inbound leads had stopped getting follow-up emails, or why the pipeline report showed a catastrophic drop in deals closed. Nothing had been lost. The contacts were all there. What had not survived was the layer above them: an automation that assigned owners on form submission, and the stage history the old reports had been quietly counting.

The data is the easy part

Almost every CRM migration plan is built around the data, because the data is what you can see and count. You export contacts, companies, deals and notes, you map fields, you import, you reconcile the row counts. This part is tedious, well understood, and rarely where things go wrong.

What breaks is everything that was built on top of those records over years of use, most of which is undocumented and some of which nobody remembers creating. A CRM in daily use is not a database — it is a database plus accumulated operational logic, and only the first half is in the export file.

What does not come across in an export

• Automations and workflows. Lead assignment rules, follow-up sequences, stage-change triggers, internal notifications. These have to be rebuilt by hand in the new system, and the ones that fail silently are the dangerous ones — nobody notices an email that was never sent.
• Historical stage transitions. Many exports give you a deal's current stage, not the dates it moved through previous ones. Any report measuring time-in-stage, conversion between stages, or velocity is computed from that history, and it cannot be reconstructed after the fact.
• Field-level edit history and audit trails. Who changed what and when usually stays behind. If you rely on this for compliance or for disputes, check before you commit, not after.
• Email threading and attachments. Messages often arrive as plain text notes stripped of threading, attachments and direction, which makes the record technically present and practically unusable.
• Integrations. Every connected tool — forms, calendar, accounting, support desk, marketing automation — points at the old system by ID. Each needs reconnecting, and the IDs on the other side will not match the new ones.
• Custom field semantics. A picklist called 'Status' with eight values that different teams interpreted differently will import cleanly and mean nothing consistent, because the shared understanding lived in people's heads.
• Permissions and visibility rules. Who could see which records rarely survives, and the default in a fresh system is usually more permissive than what you had.

Decide what history you actually need

The instinct is to bring everything. It is usually the wrong call, and it is the decision that most affects how long the migration takes. Bringing ten years of closed-lost deals, duplicate contacts and notes from staff who left in 2019 means you spend the project cleaning data you will never query, and you import your existing mess into a system you chose partly to escape it.

A more useful framing is to ask what you will genuinely look up. Open deals and active customers need full fidelity. Recent closed business needs enough to answer questions about it. Old cold records mostly need to exist and be searchable. That distinction lets you move fast on the part that matters and archive the rest — and an archived export in cold storage answers the rare historical question perfectly well.

The reporting discontinuity nobody plans for

This is the one that produces the worst moment, usually about six weeks in, when someone senior asks whether the quarter is better than the last one and the answer is that the question cannot be answered. Two things cause it: the stage history did not come across, and the new system defines its metrics differently.

Definitions drift in ways that look trivial and are not. Whether a deal's close date means expected or actual, whether a stage counts as won on signature or on payment, whether a lead becomes a contact on creation or on qualification — each choice moves the numbers. Two systems will not agree, so your before-and-after comparison is measuring the definition change as much as the business.

The practical mitigation is to freeze and export your key reports from the old system before you switch off, as static files with the numbers in them. You lose the ability to re-slice them, but you keep a defensible record of what the business looked like, and you can state plainly where the methodology changed rather than pretending the trend is continuous.

A sequence that reduces the damage

1. Inventory the automations before touching the data. Open the old system and list every workflow, trigger and sequence that exists, including the ones you think are disabled. This list is the actual scope of the migration and it is always longer than expected.
2. Inventory the integrations the same way, and identify who owns each one. A form on a site nobody has edited in two years still feeds your pipeline until the day it does not.
3. Decide the history cut-off and what gets archived rather than migrated, and write the decision down so it is not relitigated mid-project.
4. Export your critical reports from the old system as static files, with the metric definitions noted beside them.
5. Migrate a representative sample first — a few hundred records covering every record type and edge case — and have the people who use the system daily try to do their actual jobs with it.
6. Rebuild automations in the new system and test each one by triggering it deliberately. A workflow that was never fired in testing is a workflow you have not migrated.
7. Run both systems in parallel for a defined period, with one designated as authoritative, and reconcile at the end of it.
8. Switch off write access to the old system on a specific date rather than letting it linger. A system people can still edit becomes a shadow CRM, and then you have two.

The part that is not technical at all

The most common cause of a failed migration is not data loss. It is that people keep working the way they worked before, in whatever tool lets them — a spreadsheet, their inbox, the old system if it is still reachable. The new CRM then holds a partial picture, which makes it untrustworthy, which justifies not using it, which is a loop that ends with an expensive unused licence.

What breaks the loop is making the new system the only route to something people need. If the pipeline review happens from the new CRM's report, and the report is only right when the records are updated, updating the records becomes the path of least resistance. Training helps, but structural necessity is what actually changes behaviour.

A CRM nobody updates is not a cheaper CRM. It is a more expensive spreadsheet with a login screen.

When not to migrate

Migration is sometimes the wrong answer to the problem being described. If the complaint is that the current system is messy, migrating relocates the mess. If the complaint is that reporting is unreliable, and the cause is that half the team does not log activity, a new system will report the same gaps with a different chart. If the complaint is cost, compare the licence saving against the weeks of work and the reporting discontinuity honestly — the saving is often smaller than the disruption.

The cases where migration genuinely pays are the ones where the current system cannot do something you need it to do, and no amount of configuration or discipline will change that. That is a clear reason and it survives the difficult middle of the project. 'We were told this one is better' does not.

← Back to all articles