Your CRM migration won’t fail on the data. It’ll fail on a Tuesday.

A CRM migration doesn’t fail on the weekend you move the data. It fails on a Tuesday three weeks later, when a rep opens the new system, can’t find the one thing she needs, and quietly goes back to her spreadsheet.

The records moved fine. That was never the risk.

We get called in after that Tuesday more often than before it. So here’s the order that holds — and the things that get left behind every time.

A migration is not a data project

Everyone treats it like one. Export from the old system, import into the new one, count the records, the counts match, done.

Then nobody uses it.

It’s an adoption project with a data step in the middle. Get the data perfect and the team never opens the thing, and all you’ve done is move your problem into a more expensive database.

Phase one: decide what the system is for

Before a single field is mapped, answer one question. What decisions does this system need to support?

Not “what did the old one have.” What decisions.

The old CRM has three hundred and forty fields. You know this because someone ran the report. Maybe forty are filled in more than half the time. The rest are archaeology — a campaign from 2019, a manager who wanted a checkbox, an integration that was switched off before anyone currently on the team was hired.

You are not migrating three hundred and forty fields. You’re migrating forty, and making a decision on purpose about the rest. Every field you carry across is a field someone has to fill in, ignore, or explain, forever.

Phase two: make the fields identical before anything moves

Same name, same type, same picklist values, same rules about what’s required. Map all of it on paper first, while it’s still cheap to argue about.

The picklist is where it goes wrong. Your old system has stages someone named years ago: Discovery, Demo, Proposal, Negotiation, Closed Won, Closed Lost. HubSpot ships with Appointment Scheduled, Qualified To Buy, Presentation Scheduled, Decision Maker Bought-In, Contract Sent, Closed Won, Closed Lost. Salesforce ships with its own. None of them mean quite the same thing.

Nobody notices until the first forecast comes out, and the number isn’t slightly wrong. It’s a different shape.

Match them before the move, or change them on purpose and say so loudly. What you cannot do is let the import decide. It will decide. It has no opinion, so it takes the default. Stages and statuses are worth settling before you move, not after.

Phase three: clean it where it stands

Deduplicate, normalise, delete. In the old system. Before the move.

The reason is political more than technical. Cleaning after the move means cleaning inside a system nobody trusts yet, where every correction looks like a migration bug. Merge two duplicate accounts in week two and someone will ask whether the migration created them. You’ll spend the meeting proving a negative.

Decide the survivorship rules while you’re in there. When two records disagree, which one wins — the newer, the more complete, the one owned by a rep who still works here? Write it down before you need it. Otherwise it gets decided forty thousand times, quietly, by an import wizard.

And a mess doesn’t get cleaner by changing address.

Phase four: write the rules before it runs

Validation, required fields, permissions, routing, automation. Decided and switched on before the first real record lands.

The order matters more than it sounds. Import first and add validation later, and you have thousands of records breaking rules the system will never apply backwards. Your validation covers the future and quietly exempts the entire past. Nobody warns you. You find out six months later, when a report shows the mandatory field empty on four thousand rows, all of them dated before the rule existed.

Automation is the same trap in reverse. Turn the workflows on before the import and you’ll email nine thousand people to tell them their status changed. Turn them on after, and every record that came in cold never got the treatment the new ones get. Import with automation off. Then backfill deliberately, in a batch you chose, at a time you picked.

Phase five: move in slices

Not everything. Not on one weekend. Not with the whole company watching.

One object. Or one country. Or one team that likes you. Move it, watch it for a week, find what you got wrong, fix the mapping, then do the next slice.

Big-bang migrations stay popular because they’re easy to plan. They’re just very hard to survive.

Phase six: train while it’s still small

A one-hour session the week before go-live is not training. It’s a ceremony.

Train the first slice while the system is still small enough to explain in ten minutes — that is exactly what a working session on your live data is for. Those people become the ones the next slice asks. That’s the only training that scales — the kind that happens at the next desk instead of in a calendar invite.

And keep the thing simple enough that the training stays short. The test of a CRM isn’t whether a rep can use it. It’s whether they have to think about using it. If someone has to remember which of three places the note goes, they’ll pick the fastest one. That is rarely your CRM. It’s usually their notebook.

Build it so the path of least resistance is the correct path. Nobody should have to work out how to log in before they can do the job they were hired for.

Phase seven: turn the old one off

Set the date. Say it out loud. Then actually do it.

Read-only is fine. Read-only is a decision. A system that’s still writable “just for a bit, just in case” is where half your data will be next quarter — and you won’t know which half.

What gets left behind, every time

The records make it across. This is what we find missing when we’re called in afterwards.

The activity history. Notes, emails, calls, meetings, attachments. It’s the hardest thing to move and the first thing cut for time. Then a rep opens an account, sees nothing behind it, and concludes the new system is empty. They’re not wrong.

The integrations still pointing at the old system. Every webhook, every form, every enrichment tool holding an API key. Something will keep writing to the old database for months. Usually the form on the page nobody remembers owning.

The record IDs. Your finance system, your product database and your support tool all reference the CRM by ID. New system, new IDs. Keep the old one in a field — permanently — or every join you have breaks quietly and all at once.

The reports. People don’t use a CRM. They use their four saved views. Rebuild those before go-live, not on request afterwards.

Field history and the audit trail. Usually it doesn’t move at all. In a regulated business, you want to learn that during planning, not during an audit.

Permissions. Teams, roles, record visibility. Ported carelessly, the first thing a country manager notices about the new CRM is that they can now see a pipeline they shouldn’t.

The three you don’t get back

Most migration mistakes are recoverable. Three aren’t, so treat them differently from everything above.

A tested export of the old system. Taken before you touch anything, and restored somewhere once to prove it actually works. An untested backup is a rumour.

Consent and subscription status. Move it wrong and you don’t have a data problem, you have a legal one. Under GDPR, “the migration lost it” is not a lawful basis for anything.

Deletion. There is no undo. Archive instead. Decide in ninety days, when you’re calm.

Most teams run these phases in reverse, then call the result a data quality problem.

That rep with the spreadsheet was never the problem. She was the status report.