CRM Migration Checklist: The Records Arrive, the Selling Process Gets Left Behind

A CRM migration is usually scoped as an export, a mapping spreadsheet and an import. That scope moves the rows and leaves behind what gave them meaning: what each stage implied, who owned which account and why, and which quiet automations kept deals from going stale. The damage does not appear in the import log. It appears a quarter later, as a forecast nobody believes.

A CRM holds three things, and only one of them exports

It helps to separate what lives in the old system into three layers.

Data. Contacts, companies, deals, activities, attachments. This is what an export gives you.

Meaning. What "Proposal sent" required before a deal could enter it. What a probability of 60 percent was understood to imply. Why some accounts are marked "strategic". This layer lives in people's heads and in conventions, and no file contains it.

Behavior. Assignment rules, reminders, validation, approval routing, scheduled reports, integrations that push closed deals to billing. This layer is configuration and code. It does not export either, and nobody has a full list of it.

A migration that handles only the first layer produces a new system with the same records and a different business. The checklist below is organized around recovering the other two.

Object by object: what a plain copy does to each

Contacts and companies are the easy part, and even they need a deduplication policy. Everything below them requires a decision that somebody with authority has to make. The pattern to avoid is making those decisions during the import, under time pressure, by whoever happens to be holding the spreadsheet.

The stage map is not a lookup table

This is the item most often waved through, because it looks trivial. Old stage on the left, new stage on the right.

Picture a company moving from a seven-stage pipeline to a five-stage one. The old system has "Negotiation" and "Verbal commit". The new one has only "Negotiation". Merge the two and every deal that had a verbal yes is now indistinguishable from one where pricing is still being argued. The weighted forecast drops or jumps depending on the probability attached to the new stage, and no deal changed in reality.

The opposite case is just as common. One old stage, "Qualified", has to be split into "Discovery" and "Solution fit". A lookup table cannot split. Someone has to define a rule (for example, a deal with a recorded demo goes to the later stage) or the reps have to reclassify their own deals.

A usable stage map therefore has four columns: old stage, new stage, the rule for ambiguous cases, and who decides when the rule does not apply. For open deals in late stages, have the owning rep confirm the placement by hand. It is a few hours of work and it protects the number leadership will be judged on.

Do the same for anything that behaves like a stage: lead status, deal type, loss reasons, account tiers.

Custom fields are archaeology

A mature CRM has fields nobody can explain. The instinct is to drop them. Be careful: a field with no living author is often an undocumented business rule.

Suppose there is a checkbox called "Legal hold 2" on a few hundred accounts. Nobody remembers creating it. A search of the automations shows it suppresses those accounts from marketing emails. Dropping it in the migration would resume sending campaigns to customers who were deliberately excluded.

For each custom field, check four things before deciding its fate:

1. How many records have a value, and when was one last changed?
2. Does any automation, report, integration or template reference it?
3. Does any rep read it before a call or a renewal?
4. Does another team (finance, legal, support) depend on it?

Fields that fail all four can be archived to a flat file and left behind. The rest get mapped, merged or redefined.

The hardest version of this problem appears when the system you are leaving was written in-house, or bent far away from its vendor defaults over the years. Field names in such a system made sense to its original author and to almost nobody else, and that author may no longer work for you. Budget real time for reading code and querying the database directly. The schema will tell you what is stored. Only the code and the users will tell you what it means.

History: decide what you are willing to lose, and say so

Full activity history rarely survives a migration intact. Email threading, call recordings, inline images and the original author and timestamp are all fragile. You have three honest options:

• Migrate recent history in full. For example, all activity on open deals and on accounts touched in the last year or two.
• Compress older history. One summary note per account or deal, with dates and counts, plus a link to the archive.
• Keep the old system readable. A read-only license or an exported archive that people can search.

Most teams end up with a combination. What matters is that the choice is explicit and announced. Reps forgive a known gap. They do not forgive opening an account before a renewal call and finding five years of context gone without warning.

Behavior: inventory what the old system did on its own

List every automated behavior in the source system, including the ones nobody thinks of as automation:

• Assignment and round-robin rules.
• Required fields and validation at each stage.
• Reminders, escalations and stale-deal alerts.
• Approval routing for discounts or contract terms.
• Email templates and sequences.
• Scheduled reports that land in someone's inbox every Monday.
• Every integration: what it reads, what it writes, how often, and what breaks downstream if it stops.

For each one, decide whether to rebuild it, replace it or retire it. Integrations deserve the closest look, because the consumers are outside sales. Finance may be invoicing from a nightly export that nobody in the project knows exists.

Ownership disputes belong in the migration plan

If two reps already disagree about who owns an account, moving to a new system will not settle it. It will formalize whichever answer happened to be in the export. The same goes for territories that were redrawn informally, for accounts still assigned to people who left, and for house accounts nobody claims.

Treat ownership as its own workstream. Get the rules of engagement in writing from sales leadership, apply them to the data before the load, and publish the result to the team in advance. A migration is one of the few moments when cleaning this up is expected. Use it.

Choosing a cutover

There are three workable patterns. Taste should not decide between them. The volume and value of deals that are open on cutover day should.

A parallel run only works with two conditions. First, a written end date and exit criteria, or it runs forever. Second, clarity about which system is authoritative on any given day. Two sources of truth is worse than either one.

Whichever pattern you choose:

• Run at least one full rehearsal load into a test environment, with real data, and time it.
• Define a short freeze window for the final load, and tell the sales team well ahead.
• Avoid the last weeks of a quarter.
• Write the rollback plan before you need it: what triggers it, who calls it, how long it takes.

Verification beyond the row count

Matching record counts prove the import ran. They do not prove the business survived it. Reconcile on business terms:

• Total open pipeline value by stage and by owner, old versus new.
• Number of open deals per rep.
• Closed revenue by month for the last several quarters.
• A sample of accounts checked by the reps who own them, including their largest and their messiest.
• Every open deal has an owner, a stage, an amount and a next step.
• Every rebuilt report produces the same figure as its predecessor for a past period.
• Every integration has processed a real record end to end.

Have each manager sign off on their own team's pipeline. They will spot a wrong number faster than any script.

The checklist, in order

Before any export

• Inventory objects, fields, automations, integrations and reports.
• Write the stage map with rules and an escalation owner.
• Decide the fate of each custom field.
• Settle ownership and territory rules.
• Agree the history policy and the archive location.
• Profile the data for duplicates, orphans and stale records.

During build and rehearsal

• Create the ID crosswalk and keep it.
• Clean data in the source or in a staging area, not by hand in the target.
• Rebuild the automations and the short list of reports.
• Run a rehearsal load and the business reconciliation.
• Let a few reps review their own accounts in the test environment.

At cutover

• Announce the freeze, run the final load, reconcile.
• Get manager sign-off per team.
• Make the old system read-only on a stated date.

In the first month

• Keep a fast channel for "this record is wrong" reports.
• Watch the forecast against the old system's last known numbers.
• Decommission the old system only after the archive is confirmed readable.

What would your export leave behind?

If you are planning to move off your current CRM, the useful first step is an inventory of meaning and behavior, not a mapping spreadsheet. Trivo can go through your current system with you, mark what moves cleanly and what needs a decision, and lay out the cutover that fits the pipeline you have in flight.