CRM migration checklist — switch without losing your history

The two ways this goes wrong

Almost every painful CRM migration fails in one of two ways.

The big-bang cutover. Everything moves on a weekend, Monday arrives, and the pipeline is wrong in ways nobody can explain. Deals lost their stage, custom fields landed in the wrong columns, and the team is now debugging a data model while trying to sell.

The migration that never ends. Both systems stay live for months because nobody will declare the new one authoritative. Reps update whichever is nearer, both drift, and the eventual reconciliation costs more than the migration would have.

The checklist below is sequenced to avoid both: parallel running with a hard end date, and a cutover order that moves the smallest risky thing last.

Before you touch anything

1. Export everything from the old system, today. Even if you are still evaluating. Contacts, companies, deals, notes, activities, custom field definitions, users and their ownership, attachments. Store it somewhere outside both systems.

Do this first because export access disappears with the subscription. A cancelled account is frequently read-only for a short window and then gone, and planning to export before cancelling is how teams lose four years of notes.

2. Open the files and confirm they are real. A CSV that exports without error can still be missing the notes column or truncating long text fields. Spot-check twenty records against the live system.

3. Write down what you are keeping. Not everything should come. Contacts with no activity in three years, deals lost two years ago, custom fields nobody has populated since the person who created them left. Everything you migrate you will maintain, and a migration is the cheapest moment you will ever have to delete things.

4. Screenshot your automations and reports. These never migrate. They get rebuilt, and rebuilding requires knowing what they did. Capture the trigger, the conditions and the actions for each one, plus every saved report anyone actually opens.

What migrates cleanly, and what does not

Be realistic about this before you plan a timeline.

Migrates cleanly via CSV: contacts, companies, deals with stage, value and close date, owners, tags, and most custom field values as long as the field types match.

Migrates with care: notes and activity history. Usually possible, often as a bulk note import that flattens the timeline rather than preserving individual events. Decide whether flattened history is acceptable — for most teams it is, because the value is in being able to read it, not in its structure.

Does not migrate: automations, workflows, sequences, email templates with vendor-specific merge syntax, reports, dashboards, permission structures, and integrations. All of these are rebuilt.

Needs a decision: email threads. Some CRMs re-sync history from the mailbox once connected, which is the clean answer. Where they do not, you are choosing between a bulk import and accepting that the new system's history starts on day one with the old export available for reference.

The parallel-running period

Run both systems for one full sales cycle — not one week, and not indefinitely. If your average deal takes six weeks from first contact to close, run six weeks. That is the only period long enough to prove the new system handles every stage you actually use.

During parallel running:

• Name the new system authoritative from day one. Both are live, but one is the truth. Without this, you get drift instead of a test.
• Migrate open deals first, closed history second. Open deals are what the team touches daily, so they surface problems immediately. Closed history can be imported at any point and does not block anyone.
• Pick one rep as the canary. One person works entirely in the new system for the full cycle while everyone else keeps going. Their friction is your real implementation plan.
• Keep a defect list. Every wrong field and every cannot-find-X goes on a list rather than into a conversation. Most items resolve into two or three configuration fixes.

Rebuild rather than convert

For sequences, templates and automations, rebuild deliberately. Converters exist and they are a trap, because every platform models steps, delays, exit conditions and merge syntax differently, and a converted sequence that looks right can behave wrongly in ways you only discover when a prospect receives follow-up four after replying.

Rebuilding is also the cheapest audit you will ever run. Half of what you carefully recreate turns out to be something nobody has used in a year.

Two specifics worth checking as you rebuild:

• Merge fields. Different syntax, different fallback behaviour when a field is empty. Send yourself a test with a deliberately blank company name and see what arrives — a greeting addressed to nobody at nothing is a real thing that ships.
• Exit conditions. Confirm a reply stops the sequence, and confirm an out-of-office does not count as a reply. This is the most common behavioural difference between platforms and the most visible when it is wrong.

If you are also changing how you send email

Migrating CRM and changing sending infrastructure at once is common, and it introduces a risk that has nothing to do with the CRM: your sending domain reputation.

• Do not open at full volume. New sending setups ramp. A mailbox that sent two hundred a day from the old platform should not send two hundred on its first day from the new one.
• Re-check authentication. SPF, DKIM and DMARC records need to cover the new sending path, and adding a vendor to an SPF record that already has several includes can push it past the ten-lookup limit — at which point authentication fails permanently, silently, for every message from that domain.
• Verify the list before the first send. Migrated lists carry stale addresses, and a bounce spike in week one on new infrastructure is the worst possible start.

The email deliverability checklist covers the full sequence, and the SPF, DKIM and DMARC generator counts the lookups for you.

Cutover, in order

When the parallel cycle is done and the defect list is empty:

1. Announce the date a week ahead. Nothing kills adoption like a surprise.
2. Freeze the old system to read-only. This is the step that actually ends the migration. As long as writing is possible, someone will write.
3. Import remaining closed history. After the freeze, so nothing is added behind you.
4. Reconcile deal counts and values. Open deals, total pipeline value, and count by stage should match. Investigate any discrepancy before proceeding — this is your last easy checkpoint.
5. Switch integrations over. Calendar, mailbox, forms, billing. One at a time, verifying each.
6. Keep the old subscription for thirty days after cutover. The cheapest insurance in the process. Cancel once a month has passed with no one needing it.
7. Archive the exports permanently. Not in the old system, and not in the new one.

The week-one checks

• Every rep can log in and see their own records.
• A test email sends, arrives, and appears on the contact record.
• A test call logs with disposition and recording.
• A booking from a scheduling link lands on the right contact.
• Pipeline totals match the reconciliation.
• At least one report someone actually reads has been rebuilt.

A note on what you are choosing

Migration is expensive enough that it is worth using the moment well. The question to ask before you start is not only whether the new system does what the old one did, but whether it removes a job you were doing manually. Automatic activity capture, outreach in the same tool as the pipeline, or a pricing model that stops rationing visibility — those are the changes that repay a migration. Feature parity alone rarely does.

If you are still deciding, how to choose a CRM covers the evaluation order, and all-in-one versus best-of-breed covers the architecture question underneath it.