Almost nothing breaks in the actual data transfer during a CRM data migration. Contacts, companies, and deals move from one system to another without much drama, because every major CRM has an export and import path built for exactly this. What breaks is everything that was quietly built on top of the old fields, and it rarely shows up until someone on the sales team hits it mid-deal. This walks through each failure point with the mechanism behind it, then the dry run that surfaces all of it before you touch production for good.
The data is rarely the problem in a CRM migration
Moving records from HubSpot to Salesforce, Pipedrive to HubSpot, or Recruit CRM to Bullhorn is a solved, mechanical job. Export to CSV, map the columns, import. Every vendor publishes a migration guide for this exact path, and most ship a native import tool that does the grunt work, which is exactly why migration gets sold as the easy part and nobody budgets for what happens after the import finishes.
The risk isn't the data, it's the layer sitting on top of it: reports built against specific field names, automations that fire on a field changing, permission sets scoped to a role, and the muscle memory of a sales team that knows exactly where to click in the old system. None of that transfers automatically, and none of it shows up as an error during the import. Good crm hygiene in the old system (clean picklists, no orphaned fields, documented automations) makes the move easier, but it doesn't eliminate the real risk. Only testing the layer on top does.
Field mapping where the two systems don't agree on what a stage means
The field name maps across cleanly. The values inside it often don't. If your old CRM has a deal stage called "Proposal Sent" and the new one has "Negotiation," a direct mapping will drop every proposal-stage deal into negotiation, and your pipeline report is wrong on day one.
This is the single most common failure in this kind of migration, and it's invisible until someone pulls a pipeline-by-stage report and the numbers don't match what sales knows to be true. The fix is manual: someone has to map every picklist value, not just the field name, which means sitting down with the stage list from both systems side by side. This matters even more if your CRM and quoting software are integrated, because a quote status field that drives pricing logic downstream needs the same value-by-value treatment, not a one-time field match.
Duplicates the import itself creates
Most imports match contacts on email address. That works until a contact has two emails on file, a personal one from an old lead form and a work one from a later deal. The same person imports as two records, and now sales is working a duplicate without knowing it, sending two different reps after the same account.
In most B2B databases this hits a meaningful share of records, not a rare edge case. It happens on company records too, when the same account was entered once under its trading name and once under its legal name. Catching it means running a dedupe pass against secondary fields (phone number, company domain, LinkedIn URL) before the final load, not relying on the primary match key alone. This is the specific job behind the phrase crm data cleansing, and it's one of the few migration tasks worth doing twice: once before go-live, once about a month after, when post-migration entries have had time to create new duplicates of their own.
History that doesn't come across, so the pipeline looks empty
Activity logs, email thread history, and stage-change timestamps often don't migrate with the record, even when the deal itself does. Week one in the new CRM can look like a dead pipeline: deals with no notes, no call history, no sense of momentum, even though every one of them is a live, real deal.
This is a process problem more than a technical one. Whoever reads the weekly number in week one will see a pipeline that looks half the size it was, and will reasonably ask what happened. The fix is to tell that person in advance, in writing, that history won't travel and the pipeline value is still real. Pulling a snapshot report from the old system before cutover, so there's a number to compare against, closes the gap faster than any explanation after the fact.
The custom field nobody can explain
Every CRM instance that's been live more than two years has three or four fields with names like "Flag_2," "Region_old," or "Priority_X" that one person set up years ago and nobody has touched since. Most of them really are dead weight. One of them usually isn't.
Somewhere in there is a field quietly feeding a formula, a report, or an export that the finance director or ops lead reads every month without knowing which field it pulls from. Drop it during cleanup and that report breaks silently, two or three weeks after go-live, when someone finally opens it. Before removing any field with no obvious owner, check what reports, dashboards, and scheduled exports reference it, not just whether anyone remembers filling it in.
Automations and integrations that go silent, not loud
n8n flows, Zapier steps, and most CRM-to-CRM or CRM-to-ATS integrations are usually wired to internal field IDs, not the field names you see on screen. A migration regenerates those IDs. The automation doesn't throw an error, because nothing is technically broken, it just stops matching the field it's looking for and quietly stops firing.
Nobody notices for a while, because silence doesn't trigger an alert the way a crash does. The first sign is usually a lead sitting untouched for a week, or a status update that never reached the client. This bites hardest for a recruitment agency CRM running alongside an ATS, where Recruit CRM, Loxo, and Bullhorn exchange candidate and job data through exact field mappings on both sides. A CRM ATS handoff that worked for two years can go dark the day the CRM side of the pairing gets migrated, and the only way to catch it is to test the integration with a live record, not to assume it survived because the import completed.
Permissions that come across wrong
Role and territory permissions almost never map one to one between systems. A "Sales Rep" role in the old CRM might have hidden commission fields and restricted territory access; the equivalent role in the new system might not, because the new system's permission model is structured differently underneath.
After go-live, this shows up as a junior rep who can suddenly see margin or commission fields on every deal, or a rep in one territory who can now browse another territory's full account list. Checking this by role name isn't enough, because the role name doesn't tell you what it actually exposes. The only reliable check is picking one real test record per sensitive field type and confirming, logged in as each role, exactly what that user can see and edit.
The CRM data migration dry run that catches everything before go-live
Everything above has the same fix: migrate a sample, not the whole database, and use it for real work before you commit to the full load. Take roughly a tenth of your records into a sandbox instance, keep a real week of sales activity running inside it with the actual users, and write down every single fix someone had to ask for.
That count, not the record total, is the real scope of a CRM migration. A sandbox that needs eleven fixes across field mapping, duplicates, and one broken automation tells you exactly what the full migration will take to get right. This is also where a specialist earns the fee for crm data cleansing services, on the sample and the fix list, not on running the full export a second time. It's a fair question whether you need outside help for this at all: if your CRM only has a handful of automations and one clean picklist, your own ops person running this dry run is enough, and paying someone else to do it would be a waste.
The rollback question nobody asks until it's too late
Two questions get skipped in almost every migration plan: how long does the old system stay live in parallel, and who has the explicit authority to call the date it switches off. Without clear answers, teams end up running both systems for months by accident, updating records in whichever one is open.
The honest number: a migration quoted in days for the data move typically lands in two to four weeks once field mapping, permission fixes, and the dry run are counted. That gap is almost never the records. It's process decisions like this one, made late or not made at all. Naming one person with the authority to set the switch-off date, before the project starts, closes more of that gap than any tooling choice does.
Common questions
How long does a CRM data migration actually take?
Most are quoted in days for the data move itself, but land in two to four weeks once you count field mapping, permission fixes, and the dry run, because the gap is process decisions, not record counts.
Should I clean up CRM data before or after the migration?
Before, on a small sample. Run the dry run first, since it shows you which fields are actually dead weight instead of guessing at a cleanup list from memory.
What exactly is a CRM migration dry run?
Migrating about a tenth of your records into a sandbox, running a full week of normal sales work in it, and counting every fix a live user had to ask for.
How long should the old CRM stay live after cutover?
Long enough to close out any deal that was mid-stage at migration, typically two to four weeks, with one named person owning the decision to switch it off.
A CRM data migration is really a test of what you're building the new system on top of: the reports that read it, the automations that feed it, and a single source of truth for weekly reporting and job status that the whole team actually trusts. If you're not sure which of your own fields, automations, and reports would survive that dry run, the Revenue Roadmap is where we map that before anything gets moved, and it feeds straight into the kind of operations systems work that holds up after cutover.
