How to Migrate Your CRM Without Losing a Deal
A CRM migration goes wrong in exactly one way: a deal that was safe in the old system becomes invisible in the new one, and nobody notices until the buyer stops replying. Every other risk is a variation on that theme. The goal of a migration is not a clean database. It is a pipeline where not a single open deal loses its owner, its next step, or its history on the day you switch.
This guide is the playbook for making that switch safely. It covers the phases and a realistic timeline, a pre-migration checklist you can run down before touching a byte, how to map and dedupe records without merging two real companies into one, how to run the cutover over a single weekend, the risks that actually bite, and a calculator to size the effort and downtime before you commit a date.
The one rule that makes a migration safe
Treat your old CRM as read-only truth until the new one has proven it holds every open deal. A migration is not a delete-and-replace. It is a copy, a reconcile, and only then a switch. As long as the old system still contains the untouched original of every record, any mistake in the new system is recoverable, because you can always go back and compare.
That single discipline, keep the source system frozen and intact until reconciliation passes, is what separates a boring migration from a lost quarter. It costs you nothing except one extra week of paying for two tools at once, and it removes the failure mode that actually hurts: a corrupted or half-loaded record you cannot rebuild because the original is already gone.
Everything else in this guide, the checklist, the dedupe, the cutover timing, is in service of that rule. If you remember nothing else, remember that you never destroy the old until the new is proven, and you prove it by counting.
Pre-migration checklistBefore you touch a single record
The pre-migration checklist
- Inventory what you actually have
Export a full record count per object: leads, contacts, companies, deals, activities, notes, and attachments. These are your target numbers. Reconciliation later means matching them exactly.
- Freeze schema changes in the old system
Stop adding custom fields, pipelines, or automations in the tool you are leaving. A moving target cannot be mapped. Announce a change freeze to whoever administers it.
- List every integration and inbound feed
Web forms, marketing automation, billing, calendar, dialers, Zapier flows, and any API writing into the CRM. Each one is a pipe you will re-point during cutover. A missed feed silently drops leads on the floor.
- Decide what does not come with you
Dead leads older than a defined cutoff, duplicate junk, test records, and abandoned custom fields nobody reads. Migrating garbage just makes the new system feel like the old one. Archive it, do not import it.
- Name a single owner and a rollback trigger
One person owns the go or no-go call. Write down in advance the specific condition that aborts the cutover and reverts to the old system, so nobody has to improvise that decision at 2am on Saturday.
- Communicate the freeze window to the team
Reps need to know the exact hours the CRM is read-only, where to log deals in the meantime, and when the new system opens. Surprise downtime is how deals get worked in a spreadsheet and then lost.
Data mapping and deduplication
Mapping is the unglamorous heart of a migration. For every field in the old system you make one of three decisions: it maps cleanly to a field in the new one, it needs a transform first, or it gets dropped. The trap is the silent fourth option, a field that just does not make the jump because nobody noticed it. That is how a rep loses the note that said the buyer only takes calls after 4pm. Build the map as an explicit spreadsheet: source field, destination field, transform rule, owner. If a row has no destination, that must be a deliberate choice, not an accident.
Transforms are where formats bite. Picklist values that were free text become a fixed set, dates change format, phone numbers gain or lose country codes, and owner names must match real user accounts in the new system or the records land ownerless. Ownerless open deals are invisible deals, so map every old owner to a new user before you import, and hard-fail any record whose owner does not resolve.
Deduplication is the other half. Old CRMs accumulate the same company under three spellings and the same person under two emails. Dedupe on stable keys, a normalized email or a domain plus a normalized company name, not on display text that varies. And be conservative: a false merge that fuses two genuinely different companies is far harder to unwind after go-live than a leftover duplicate you clean up next week. When in doubt, do not merge. Flag it for a human.
Go-liveThe weekend cutover
The cutover runbook
- Friday evening: freeze the old system
Set the old CRM to read-only or announce a hard stop on edits. From this moment the old system is a frozen snapshot. Any deal activity happens in a designated holding doc until the new system is live.
- Export the final delta
Pull everything that changed since your dry-run export. This delta is small because most of the data was already loaded and validated during the dry run. You are only catching the last few days of edits.
- Load and reconcile one last time
Import the delta into the new system and re-run the count and pipeline-value reconciliation. Open deals and total value must equal the frozen old system to the dollar before you proceed.
- Re-point every integration
Switch web forms, marketing automation, billing, calendar, and API feeds to write into the new CRM. Send a test lead through each pipe and confirm it lands. A form still posting to the dead system is a silent leak.
- Open the doors and watch
Let reps in. Keep the old system available read-only for a week so anyone can cross-check a deal. Watch new-lead flow and follow-up activity closely for the first 48 hours, which is when a missed integration shows up.
- Decommission only after parallel proof
After a week of clean parallel running with counts still tied out, export a final archive of the old system and turn it off. Not before. The archive is your permanent safety net.
The real risks, and how to blunt each one
- A frozen source system means every mistake is recoverable by comparison.
- A dry run into a sandbox catches mapping errors before they reach reps.
- Dollar-for-dollar reconciliation proves no open deal was lost.
- A week of parallel running turns go-live into a checkable claim, not a leap of faith.
- Ownerless records: unmapped owners create invisible deals. Fix by hard-failing any record whose owner does not resolve to a real user.
- False merges: aggressive dedupe fuses two real companies. Fix by deduping on stable keys and flagging ambiguous matches for a human.
- Dropped integrations: a form still posting to the old system leaks leads. Fix by testing every pipe end to end at cutover.
- Lost history: notes and activities left behind gut the context reps rely on. Fix by mapping activities and attachments explicitly, not just the deal record.
- Cutover during business hours: edits made mid-migration get stranded. Fix by cutting over on a weekend with a clear freeze window.
Migration effort and downtime calculator
Size the job before you commit a date. This models the rough hours of hands-on migration work and the freeze window your team should plan around. Adjust the inputs on the live page to match your own data.
| Field mapping and transform hours | 20 |
|---|---|
| Dedupe and cleanup hours | 4 |
| Integration re-point hours | 9 |
| Estimated hands-on hours | 37 |
| Recommended freeze window (hours) | 8 |
Where migrations typically slip
What makes the destination CRM easy or hard to migrate into
| Migration factor | Ardovo | Legacy CRM | Spreadsheet |
|---|---|---|---|
| Guided import with mapping preview | Yes | Partial | No |
| Sandbox or reset workspace for a dry run | Yes | Partial | No |
| Built-in dedupe on stable keys | Yes | Partial | No |
| Live and usable on first load | Yes | No | Yes |
| AI operator validates and enriches on import | Yes | No | No |
| Time from import to working pipeline | Minutes | Weeks | None |
| One flat price during a dual-run overlap | Yes | No | Yes |
Legacy CRM column reflects a typical seat-plus-add-on configuration with migration tooling gated behind higher tiers or paid services.
We froze the old system Friday, reconciled the counts twice, and reps were working their real pipeline in the new tool Monday morning. Not one open deal went missing.
Why the destination matters as much as the process
A disciplined process protects you no matter what you migrate into. But the destination system decides how much of that discipline you have to enforce by hand. A CRM that is alive on first load, with a guided import that previews your mapping, built-in dedupe, and an operator that validates and enriches records as they land, removes whole categories of manual work and whole classes of error.
This is where Ardovo is built for the switch rather than against it. It is live and usable the moment your data lands, so there is no blank-database configuration phase between import and value. Rook, the built-in AI operator, checks owners, flags likely duplicates, and fills gaps as records come in, so reconciliation is a confirmation rather than a scavenger hunt. And because Ardovo is one flat price across every module, the week you run both systems in parallel does not trigger a per-seat penalty on the tool you are still turning off.
None of that replaces the rule at the top of this guide. You still freeze the old system, still reconcile to the dollar, still run in parallel before you decommission. A good destination just means the safe path is also the fast one.
Frequently asked questions
How long does a CRM migration take?
For a mid-size team, plan on roughly three weeks end to end: about a week to audit and plan, a week to map and clean the data with a full test import, and a weekend cutover followed by a week of parallel running. The actual switch happens over a single weekend. Small teams compress this and heavily customized orgs stretch it, but the phases stay the same.
How do I make sure I do not lose any deals?
Keep the old system frozen and read-only until you have proven the new one holds everything. The proof is reconciliation: the count of open deals and their total pipeline value in the new system must equal the old system to the dollar before you turn anything off. Then run both in parallel for about a week so you can cross-check any deal.
Should I migrate all of my historical data?
No. Deliberately leave behind dead leads past a defined cutoff, duplicate junk, test records, and custom fields nobody uses. Archive that data, do not import it. Migrating garbage just recreates the mess you were trying to escape. Bring the open pipeline, active accounts, and the history and notes attached to them.
What is the safest time to run the cutover?
A weekend, with a clearly communicated freeze window. You want the lowest possible volume of live edits during the switch, and you want reps to know exactly when the system is read-only and where to log anything urgent in the meantime. Cutting over mid-week during business hours is how edits get stranded between the two systems.
What is the most common thing that goes wrong?
A missed integration. A web form, marketing tool, or API feed keeps writing into the old system after cutover, so new leads land somewhere nobody is watching. Prevent it by inventorying every inbound feed before you start and sending a test record through each one at cutover to confirm it lands in the new CRM.
Do I need to pay for two CRMs at once?
For a short overlap, yes, and it is worth it. Running both systems in parallel for about a week is what lets you verify nothing was lost before you decommission the old one. Choosing a destination with one flat price, like Ardovo, keeps that overlap from triggering a per-seat penalty on the tool you are shutting down.
Run your revenue on Ardovo
Everything alive on first load. Ask Rook and it does the work.