The Migration Checklist Before You Move CRMs

You are not stalling on a CRM switch because of price. You are stalling because nobody wants to own the morning after, when the records are in the new system but half the contacts are duplicated, three sequences are mid-flight to people who already bought, and the pipeline report does not match the number you presented to the board last week.

Here is the honest answer: migrations do not fail on data movement. They fail on five decisions nobody wrote down before someone hit export. Make those decisions first, in writing, with a name next to each, and the switch takes a day. Skip them and you get a quarter of cleanup that you will call "the migration" forever.

Why CRM migrations fail on decisions, not data

Moving rows between systems is the easy part. The expensive part is that every CRM encodes judgment calls: what counts as a lead versus a client, which stage means committed revenue, who owns a record when the rep who owned it left. Those judgments live in field names, picklists and workflow conditions. Export strips the judgment and keeps the values, and the new system has no idea what you meant.

The classic failure is scope left on default. In one documented enterprise sync at a 1,000 employee advisory and asset management firm, nearly all contacts were syncing automatically between the two systems, and remediation removed tens of thousands of duplicate records, with the same person routinely existing as a client in one system and a lead in the other. The root cause was sync eligibility criteria that had never been defined, not a software bug.

That is the whole lesson. Default scope is a decision. You just let the tool make it.

The five decisions to make before you export anything

Write the answers down. One page. One owner per answer.

1. The object model. Decide what objects you actually need in the new system, not what exists in the old one. Most CRMs accumulate custom objects because adding one was easy. In documented rebuilds, teams have collapsed dozens of custom objects down to a handful, and large member associations have run on a single digit number of data objects with real-time syncing. Complexity is not fidelity. Start from the questions you need the CRM to answer and work backwards.

2. The field map. Every field in the export gets one of three fates: migrate, merge, or drop. As a working rule, treat fields with a very low fill rate as abandoned experiments until someone defends them. Fields holding free text where a picklist belonged are the reason your reporting never worked. Decide the destination property type now, because a date stored as text will not sort, filter or trigger anything once it lands.

3. Owner and lifecycle mapping. This is where records fail on write. Picklist and stage values with no equivalent in the destination, and records owned by deactivated users, are a common cause of sync failures in enterprise CRM integrations. Retiring a pipeline stage is a commercial decision, not a technical one, so make it with your sales leader in the room. Decide in advance where orphaned records go: a named house account beats a blank owner field, because blank owners silently drop out of every report and every routing rule.

4. The deduplication rule. Pick the match key before the import, not after. Email is the usual primary key for contacts, domain for companies, and you need a stated tiebreak: most recently engaged record wins, or most complete record wins. Then decide what happens to the loser, merged or archived. Without a written rule, duplicates are resolved one at a time by whoever notices, which is how 30,000 of them accumulate.

5. What history actually comes over. The default answer, "everything," is the most expensive one you can give. More on that below.

"Bring everything" is the costly option

Two reasons, one financial and one operational.

Financially, platforms that bill on contact volume charge you for every record you bring. Importing five years of untouched records means paying a per contact tax on people who will never open anything again. B2B contact data decays at roughly 2.1% per month, compounding to about 22.5% per year, in a widely cited decay model built on MarketingSherpa research (Airscale). That is a model output, not a measured outcome, and the same model leaves roughly half a list valid at three years.

Operationally, it poisons scoring on day one. Lead scoring and dynamic audiences read engagement and recency. Fill the database with stale records and every score distribution shifts, every "hot lead" list gets noisier, and your reps learn within a week not to trust the number. That distrust is very hard to recover.

So set an eligibility rule. Something like: contacts with any activity in the last 24 months, plus all contacts attached to an open or won deal, plus anyone on an active subscription. Everything else goes to cold storage in a file you keep, not into the system you pay for.

There is a second constraint worth knowing: a platform can cap how far back activity history carries, and the window may be measured from the date the record syncs rather than from today, so check the destination's own limits. Activity sync limits vary by platform and by integration, so read the destination vendor's own documentation for the windows that apply to email events, form submissions and logged activities before you plan around them. The same documentation will tell you how many contact associations a single activity can carry, which matters because enterprise meetings are rarely one to one. If three years of call notes are legally or commercially necessary, that is a separate workstream with its own plan, not a checkbox on the import.

The automation freeze

Migrations break the sending and routing layer, not the records. Records sit still. Automations keep running.

Before any export, produce a single inventory of everything that fires: active workflows, email sequences with contacts mid-flight, lead routing rules, form submissions, chat handoffs, integrations writing into the CRM from billing, support or your website. Mark each one freeze, rebuild, or retire.

Audit the old system's rules too. Sync errors often trace back to custom code, validation rules and flows that block an incoming write, and those rules are usually undocumented, which is how a parallel run quietly fails at 2am.

Assume the rebuild is bigger than it looks. A single enterprise migration can mean converting more than a hundred email templates, rebuilding every customer journey as a workflow in the destination system, and reconstructing dozens of dashboards and reports. None of that is data. All of it is work you will discover on day two if you do not list it on day zero.

Cutover day: access, owners, and the one hour reconciliation

Two things get forgotten in the last 24 hours.

Access. Decide before cutover who holds admin, who logs in first, how every rep gets credentials, and what happens to records owned by users you are not bringing over. A rep who cannot sign in on Monday morning will go back to the old system, and then you have two sources of truth, which is worse than having one bad one.

Reconciliation. Run these four checks inside an hour of cutover, and set the rollback trigger before you start, not during the panic:

• Record counts by object, source versus destination, with the expected gap from your eligibility rule stated in advance.
• Open deal totals by stage and total pipeline value. These must match to the dollar or you have a stage mapping problem.
• Owner assignment coverage. Zero records with a blank owner. Anything unassigned goes to the house account you already named.
• Spot check a sample of records by hand across your most important segments. Field by field. It is the check that finds what the counts hide.

Week one validation

Counts matching does not mean the system works. In the first week, check the live layer:

• Forms write to the right properties, and no form is pointing at a field you retired.
• Tracking fires on every key page, so visits and company activity actually attribute.
• Sending domain is authenticated before the first campaign, not after a deliverability incident.
• Reporting reproduces last quarter's pipeline totals from the old system. If it does not, the gap tells you exactly which mapping decision was wrong.
• Routing sends a real test lead through form to score to owner to notification, end to end.

Then, one month in, look at what nobody is using. The fields still empty, the workflows that never fired. That is your proof the field map was honest.

Payani AI was built for the team that has to do all of this while still hitting the number, with contacts, companies, deals, email, forms, tracking, scoring and reporting on one brain so there is nothing left to stitch back together afterwards. Switch handles the move itself, and Ask Payani is there on every screen when you need a straight answer about what the data is telling you.

Frequently asked questions

How long should a CRM migration actually take?

The data transfer is the fast part. What stretches a migration into a quarter is the decisions you make after the import instead of before it: dedupe rules, stage mapping, orphaned owners and rebuilt automations. If the five decisions are written down with an owner each before any export, the move itself is short and week one becomes validation rather than firefighting.

Should we migrate all of our historical contacts?

Usually no. Most platforms bill per contact, and contact data decays at roughly 2.1% per month, about 22.5% a year, in a widely cited decay model built on MarketingSherpa research. Stale records also distort lead scoring from day one, which is how reps learn to distrust the system. Set an eligibility rule such as any activity in the last 24 months plus anyone attached to an open or won deal, and keep the rest in cold storage.

What breaks most often during a CRM switch?

The sending and routing layer, not the records. Sequences mid-flight, lead routing rules, forms pointing at retired fields, integrations writing in from billing or support, and reporting that no longer matches the old pipeline totals. Inventory every active workflow, sequence and integration before you export, and mark each one freeze, rebuild or retire.

What do we check in the first hour after cutover?

Four things: record counts by object against the source, open deal totals by stage and total pipeline value, owner assignment coverage with zero blank owners, and a manual spot check of a sample of records across your key segments. Set the rollback trigger before you start so the decision is already made if the numbers do not line up.

Why do duplicate records appear after a migration?

Because the match key was never defined, so the tool used its default scope. In one documented enterprise migration at a 1,000 employee advisory firm, nearly all contacts were syncing automatically and remediation removed tens of thousands of duplicates, with the same person existing as a client in one system and a lead in the other. The cause was criteria that were never defined, not a software bug.