A CRM migration is the process of moving your revenue data, workflows, and team from one CRM to another. The fear of migration keeps more companies on the wrong CRM than any feature ever has. The fear is rational only if you plan to move everything. The teams that migrate cleanly move the 20 percent of data that runs the business, leave the sediment behind, and run a short parallel period around live deals. Done that way, a migration is measured in days or weeks, not quarters: our completed migrations have run from a single day to about four weeks end to end.
Reframe the Project: Migration Is Curation
A five year old Salesforce or HubSpot instance is not a database. It is an archaeological site: fields nobody remembers creating, workflows that fire into the void, thousands of contacts who bounced three jobs ago. Migrating all of it faithfully reproduces your problems in a new system. The correct instinct is the opposite of completeness. Decide what the business actually runs on, move that with high fidelity, and archive the rest as a read only export you will almost never open.
This is also why "we have too much customization to leave" is weaker than it sounds. Most of that customization exists to compensate for the old system's structure. In a CRM with a native B2B software data model, a large share of custom fields have a built in equivalent or become unnecessary, because things like qualification frameworks, renewal objects, and ARR metrics are part of the product rather than something an admin assembled. In our recent Salesforce migrations, roughly 42 percent of legacy custom fields either mapped to a native equivalent or were dropped without loss.
What to Move, What to Archive
Move: open pipeline. Every open deal with full fidelity: amount, stage, close date, contacts, and activity history for the trailing six months. This is the zero data loss zone.
Move: customers and renewals. Active accounts, contract values, renewal dates, key stakeholders, and open expansion opportunities. Your retention motion depends on these being exact.
Move: recent closed lost. The last 12 to 18 months, with loss reasons. This is your nurture pool and your baseline for win rate analysis.
Move selectively: contacts and accounts with signal. Named ICP accounts and contacts with engagement in the last year. A 200,000 record contact database with 8,000 real relationships is a liability, not an asset.
Archive, do not move: everything else. Old activities, dead leads, legacy attachments, and closed deals beyond the analysis window live in a read only export. In practice these are consulted a handful of times and then never again.
The Migration Sequence
Week 1: Map and clean at the source
Map your old objects and fields to the new system's model, and be honest about which custom fields earned a place. Fix the worst data quality issues before export, not after import: duplicate accounts, orphaned contacts, deals with no close dates. Cleaning in the old system means you migrate once instead of twice.
Week 2: Migrate structure, then history
Load accounts and contacts first, then open deals, then activity history. Validate with counts and spot checks at each layer: does open pipeline total in the new system match the old one to the dollar? Reconcile before anyone works in the new system, because trust in a CRM is lost exactly once.
Week 2 to 3: Parallel run on live deals only
Run both systems for one to two weeks, but only for open opportunities, with the old CRM in read only for everything else. Long parallel periods are where migrations die; the goal is a short overlap that protects in flight deals through one full forecast cycle.
Week 3 to 4: Cut over with a forcing function
Pick a Monday. Old system goes read only for everyone, forecast runs from the new system that Friday, and leadership refuses to accept pipeline reviews from the old one. Adoption is a leadership behavior, not a training problem. Reps adopt whatever system their forecast is judged from.
How AI Changed Migration Math
The historic argument against switching was accumulated context: years of notes and activity that felt impossible to replicate. That argument has inverted. When the destination system captures calls, emails, and meetings automatically and reasons over them, it rebuilds richer context on active accounts within weeks than most legacy instances accumulated in years of manual entry, because the manual entry never actually happened. In Dreamhub migrations, teams run their first forecast out of the new system a median of six days after go live: about two days for small migrations, extending to two weeks for larger ones. The deal records reps see thirty days after cutover routinely contain more usable intelligence than the records they left behind.
Time to switch is one of the questions to pressure test in any evaluation, and vendors serious about displacement will show you their onboarding data rather than a slide.
FAQ
How long does a CRM migration take?
For a B2B software company with a curated scope, days to about four weeks from kickoff to cutover; our completed migrations have run from one day to roughly four weeks, and teams forecast out of the new system a median of six days after go live. Migrations that take quarters are almost always trying to move everything.
Will we lose historical reporting?
You keep a read only archive of the old system's exports, and you move enough closed deal history, typically 12 to 18 months, to preserve win rate and cycle baselines. Older history is available but rarely consulted.
When is the right time to migrate?
Immediately after a quarter close, never mid quarter. The parallel run should span one forecast cycle, not one fiscal quarter.
What is the biggest migration mistake?
Moving everything. The second biggest is a long parallel period, which splits the team's source of truth and guarantees neither system is accurate.