CRM migration checklist — switch without losing your history

A CRM migration is a reconciliation, not a copy. Records move in an afternoon; what takes the time is proving that what arrived is what left, and the proof is a set of counts that have to balance at each step. Teams that treat it as a copy discover the discrepancies weeks later, when a pipeline number is wrong and nobody can say which of forty decisions caused it. This checklist is sequenced around the invariant you check at each stage and the failure that invariant catches.

The two ways this goes wrong, and what they have in common

The big-bang cutover. Everything moves over 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 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.

What both have in common is the absence of a checkable claim. Neither approach ever states, at any moment, "these two numbers should be equal and here is the query that shows they are." Everything below exists to produce that statement at each step.

Export everything today, before you have decided anything

Do this while you are still evaluating, not when you have chosen. Export contacts, companies, deals, notes, activities, custom field definitions, users and their ownership, and attachments. Put the files somewhere outside both systems.

The reason for the urgency is access rather than diligence. Export permission 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 to a billing date.

Then open the files, because a CSV that exports without error can still be missing the notes column or truncating long text at some vendor limit. Spot-check twenty records against the live system, field by field. The invariant here is that the row count in the file equals the record count the product reports. If it does not, you have found the truncation before it becomes a data-loss incident rather than after.

Finally, write down what you are deliberately not taking. Contacts with no activity in three years, deals lost two years ago, custom fields nobody has populated since their author left. Everything you migrate you will maintain, and a migration is the cheapest moment you will ever have to delete something.

Four classes of object, sorted by how they actually move

Classify every object before you plan a timeline, because the four classes have wildly different costs.

Class one — moves as a row. Contacts, companies, deals with stage and value and close date, owners, tags, and most custom field values where the field types match. These are a CSV and an afternoon.

Class two — moves as a flattened blob. Notes and activity history. Usually possible, often as a bulk note import that collapses a timeline into text rather than preserving individual events. Decide explicitly whether flattened is acceptable; for most teams it is, because the value is in being able to read the history rather than in querying it.

Class three — must be rebuilt. Automations, workflows, sequences, templates with vendor-specific merge syntax, reports, dashboards, permission structures and integrations. There is no import for any of these and the converters that claim otherwise are a trap.

Class four — must be decided. Email threads and stage history. For email, some systems re-sync from the mailbox once connected, which is the clean answer; where they do not, you are choosing between a bulk import and accepting that history starts on day one with the export kept for reference. Check where those threads land afterwards too, because a single queue holding replies from every channel and a per-mailbox folder view are different products wearing the same word.

Stage history deserves its own warning because it is the one people assume is class two and is usually class four. Many CRMs, Autocloz included, store a single stage-entered timestamp on the deal and overwrite it at every transition. That gives you current dwell time and nothing else — the path a deal took through the pipeline is not recorded, so it cannot be exported, so it cannot be migrated. If "which stage do our deals die in" is a question you need answered, the answer has to start being recorded now, in the new system, and it will never exist for the old one.

Build the identity map before you import anything

This is the step that separates a migration you can repeat from one you can only do once.

For every object you move, keep a two-column table: the old system's identifier and the new one's. You will need it three times — to re-point activities and notes at the right parent, to re-point list memberships, and to run the second pass when the first import reveals a mapping error. Without the map, a second pass means matching on names, and matching on names is how you create the duplicates you spent the previous week removing.

While you are here, learn the target system's match rule, because it decides which duplicates you get. Autocloz matches an incoming row against an existing lead on any of three identifiers — email compared case-insensitively, phone compared after every non-digit is stripped, or an exact LinkedIn URL string — and takes the first match. Two colleagues who both entered the company switchboard number will merge into one lead; two spellings of the same LinkedIn profile will stay two people. Normalise before you import: lowercase the emails, strip the phone formatting yourself, canonicalise the URL form, and lowercase every tag, because the leads filter lowercases the tag you search for and the stored value is compared literally.

One more behaviour to know before you count anything. A row carrying no email, no phone number and no LinkedIn URL cannot become a lead at all, and Autocloz's import counts it as skipped rather than created. That is honest, and it means the number of rows you uploaded and the number of leads you now have are two different numbers by design.

Parallel running, with a hard end date decided in advance

Run both systems for one full sales cycle — not one week, and not indefinitely. Six-week average cycle, six-week parallel period. That is the shortest window long enough to exercise every stage you genuinely use.

Four rules make the period a test rather than a drift.

• Name the new system authoritative from day one. Both are live; one is the truth. Without this you get divergence instead of evidence.
• Migrate open deals first and closed history second. Open deals are touched daily, so they surface problems immediately. Closed history blocks nobody and can land at any point.
• Pick one canary. One rep works entirely in the new system for the full cycle while everybody else carries on. Their friction is your real implementation plan, and it is more informative than every evaluation call combined.
• Keep a written defect list. Every wrong field and every cannot-find-X goes on the list rather than into a conversation. Most items collapse into two or three configuration fixes; the rest are the decision about whether to proceed.

Rebuild sequences and automations rather than converting them

Converters exist for cadences and they are a trap, because every platform models steps, delays, exit conditions and merge fallbacks differently. A converted sequence that looks right can behave wrongly in ways you discover when a prospect receives follow-up four after replying.

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

Three specifics to check as you rebuild.

Merge fallbacks. Different syntax, different behaviour when a field is empty. Send yourself a test with a deliberately blank company name and read what arrives. A greeting addressed to nobody at nothing is a real thing that ships, and no layer errors when it does.

Exit conditions. Confirm a reply stops the sequence and confirm an out-of-office does not. That is the most common behavioural difference between platforms and the most visible when it is wrong. In Autocloz a human reply stops the enrolment and stamps a reason, a hard bounce stops it and suppresses the address, and an auto-responder leaves it running deliberately.

Cross-channel stop. If your cadence mixes channels, test whether a reply on one stops the others rather than assuming it. In Autocloz an inbound SMS or WhatsApp message does not stop an email enrolment; a recognised opt-out keyword adds a do-not-contact entry against that phone number and closes the conversation, while the email steps continue.

If the sending domain moves at the same time

Changing CRM and sending infrastructure together is common, and it adds a failure mode with nothing to do with the CRM.

Re-check authentication before the first send. SPF, DKIM and DMARC records have to cover the new sending path. Adding one more include to an SPF record that already has several can push it past the limit in RFC 7208 section 4.6.4, which requires implementations to cap DNS-querying terms at ten during evaluation and to return permerror beyond that — at which point authentication fails permanently and silently for every message from the domain. The SPF, DKIM and DMARC generator counts the lookups for you.

Do not open at full volume. 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. New sending paths ramp, and in Autocloz the mailbox warmup runs 21 days on a smoothstep curve, so plan capacity three weeks ahead of when you need it rather than on the day.

Verify the list before the first send. Migrated lists carry stale addresses, and a bounce spike in week one on infrastructure with no reputation is the worst possible start. It matters more than it used to: Google requires bulk senders — 5,000 or more messages a day to Gmail accounts, from 1 February 2024 — to keep the spam rate reported in Postmaster Tools below 0.30%, and Microsoft began applying its own high-volume sender requirements to consumer Outlook accounts on 5 May 2025, routing non-compliant mail to Junk before rejecting it outright. How to clean an email list covers the order to do that in.

Cutover, in the order that keeps the pipeline intact

When the parallel cycle is done and the defect list is empty, run these in sequence. The order is chosen so the smallest risky thing moves last.

1. Announce the date a week ahead. A surprise cutover destroys adoption faster than any missing feature.
2. Freeze the old system to read-only. This is the step that actually ends the migration. While writing is possible, somebody will write.
3. Import the remaining closed history. After the freeze, so nothing is added behind you.
4. Reconcile. The section below. Do not proceed past a discrepancy; this is your last cheap checkpoint.
5. Switch integrations one at a time, verifying each. Calendar, mailbox, forms, billing.
6. Keep the old subscription for thirty days. The cheapest insurance in the process.
7. Archive the exports permanently, outside both systems.

Autocloz's free plan covers 5 users, 10 mailboxes and 100,000 contacts, which is enough to run a real parallel period rather than a sample of one — start free and import a live segment rather than a test file.

A worked reconciliation that catches what a total hides

Numbers below are an illustrative worked example rather than measured data. The method is the point.

Contacts. The source export has 12,480 rows. Of those, 1,247 carry no email, no phone and no LinkedIn URL, so 11,233 are importable. The import reports 10,908 created and 325 matched against existing records. Check: 10,908 + 325 + 1,247 = 12,480. The invariant holds, and the 1,247 are now a documented decision rather than a silent loss.

Deals, the naive check. The source reports 638 open deals worth ₹4.62 crore in total. The target reports 638 open deals worth ₹4.62 crore. Both numbers match, and it is tempting to stop.

Deals, the check that matters. Count by stage on both sides and compare stage by stage. Source: 210 in Qualified, 173 in Proposal, 141 in Negotiation, 114 in Contract. Target: 214, 173, 141, 110. Total unchanged, value unchanged, and four deals have moved from Contract into Qualified — because those four sat in a stage whose name did not exist in the target, and the importer put them in the default column.

That is the entire argument for reconciling by segment rather than by total. Four deals in the wrong stage is a forecast that is wrong by the value of your four latest-stage opportunities, and no total will ever reveal it. Run the same shape of check on owners — count of records per owner, both sides — because unassigned records are the other thing a total hides.

Week one checks, after the reconciliation passes. 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 a disposition. A booking from a scheduling link lands on the right contact. At least one report somebody actually reads has been rebuilt.

What does not migrate at all, and what the export leaves behind

Six things to accept rather than plan around.

Stage history, for the reason above. It is not in the export because it is not in the source.

Automation logic, in both directions. You will rebuild leaving and you would rebuild arriving.

Permission structures. Roles, field-level visibility and record-sharing rules are modelled so differently between products that a copy would be misleading even if it were possible.

Attachment context. Files usually move; the association between a file and the specific email or note it came from frequently does not.

Anything computed nightly. Cached scores, heat numbers and rollups are outputs, not inputs. Re-derive them in the new system; importing them means importing a number the new system cannot reproduce or explain.

And the honest note about leaving Autocloz, because a page that only describes arriving is not worth trusting. Its leads export is a nine-column CSV — email, name, company, status, phone, LinkedIn URL, score, source and creation date — capped at 100,000 rows, and it does not include custom fields, notes, tags, owner or the activity timeline. That is the file's real scope. Ask exactly the same question of every vendor on your list before you sign, not after: what comes out, in what format, how many columns, and can you get it yourself. How to choose a CRM makes that a probe you run on day one of a trial, and the Autocloz and Zoho CRM comparison is an example of the level of detail worth demanding before a migration rather than during one.