A CRM migration is one of the few projects where the technical part is the easy part. Exporting records and mapping fields is a solved problem. The quarter gets lost somewhere else, and almost always in the same three places.
Decide the process before the data
The first failure is starting with an export. Teams open the old system, look at 340 fields, and begin deciding which ones map where. Six weeks later they have faithfully reproduced a configuration that nobody liked, in a system that now also feels unfamiliar.
The order that works is the opposite. Write down how you want to sell, then build that, then move only the data it needs.
Practically, that means settling four things on paper before anyone touches an export:
- Your pipeline stages and their exit criteria, covered in defining stages that hold
- What qualifies as an account, a contact and an opportunity, since most old systems have blurred all three
- Who owns what, by territory or segment or round robin
- The handful of reports the business actually runs on
That last one is the highest-value hour of the project. Most companies have four or five reports that genuinely drive decisions, sitting inside a library of ninety that nobody opens. Build for the five.
What actually needs to move
The instinct is to bring everything, on the grounds that you might need it. The cost of bringing everything is that your new system launches full of records nobody trusts, which is the condition you were trying to escape.
| Record type | Move it? | Reasoning |
|---|---|---|
| Open opportunities | Yes, all | Live revenue. Re-stage them against the new criteria as you go. |
| Active accounts and contacts | Yes | Anything touched in the last 18 months. |
| Closed-won history | Yes, trimmed | Enough for year-over-year reporting and renewals. |
| Closed-lost history | Summary only | Keep the reason codes and dates. The email threads can stay behind. |
| Dormant contacts | Export to cold storage | Recoverable if needed, invisible day to day. |
| Old custom fields | Almost never | If nobody can explain what one is for, that is your answer. |
Dormant records deserve a note. Contact data decays continuously as people change jobs, so a contact untouched for two years is closer to a guess than a record. Moving it makes your new database look fuller and perform worse.
A four-week plan
Week one: decide
No exports yet
- Stages, exit criteria and required fields agreed with the reps who will use them
- The five reports that matter, written down with their definitions
- Ownership rules and routing logic settled
- A cutover date chosen, early in a quarter rather than late
Weeks two and three: build and map
In parallel, not in sequence
- New system configured to the week-one decisions
- Field mapping written as a document, reviewed by someone who did not write it
- Test migration run with a real subset, ideally one full territory
- Reps given access to the sandbox and asked to break it
Week four: verify and cut
The only week with real risk
- Full dry run with record counts reconciled against the source
- The five reports rebuilt and compared line by line with the old ones
- Training, which needs an hour rather than a day if week one was done properly
- Cutover, with the old system made read-only the same day
The cutover weekend
Three rules make the difference between a quiet Monday and a bad fortnight.
Freeze writes on Friday. Announce a window where nobody edits the old system. A few hours of frozen data beats a week of reconciling records that changed during the migration.
Reconcile counts before anyone logs in. Open opportunities, total pipeline value, account count, contact count. If the numbers do not match the source, stop and find out why on Saturday rather than discovering it in Tuesday's pipeline review.
Make the old system read-only immediately. This is the rule teams skip, and skipping it causes the single worst migration outcome: two partial versions of the truth, maintained by different people, for three weeks. If reps can still work in the old system, some of them will.
The two weeks after
Expect a dip. Everyone is slower in an unfamiliar system for about ten working days, and pipeline hygiene usually looks worse immediately after a migration because the new exit criteria are stricter than the old ones. That drop is the criteria doing their job.
Three things to watch daily for the first fortnight:
- Records created in the wrong place. Usually a form or integration still pointing at the old system.
- Routing gaps. Leads landing without an owner, which is the failure that costs the most per occurrence. Worth reading alongside speed to lead.
- Reports that disagree. Any gap between the new report and the old one needs an explanation, even when the new number is the better one.
Run a retro at the two-week mark with the reps, not just the person who ran the project. The gap between what was built and what people actually do is easiest to close while the system is still new enough to change without another migration.
If you would rather have someone else carry this, migration onto Throughline is the middle third of the ninety days, and the week-one decisions are the part we insist on doing properly.
Frequently asked questions
How long does a CRM migration take?
Should we migrate all our historical CRM data?
What is the biggest risk in a CRM migration?
Can you migrate a CRM mid-quarter?
Zachary works with founder-led B2B SaaS companies between seed and Series B, as a fractional VP of Sales and Marketing and through the team that builds their revenue operation on Throughline.
Get a free GTM teardown