CRM Migration: Your Rollback Plan Has an Expiry Date

The import finishes on Sunday night. Record counts match on both sides. On Wednesday, three reps ask why their forecast is empty, marketing finds that half the contacts have no lifecycle stage, and the ops lead discovers that every account with a parent company got flattened into one tier.

Nothing failed. That is the uncomfortable part of a CRM migration: the thing that goes wrong is almost never the transfer. It is a set of decisions you made about your data model three weeks earlier, which the import then executed perfectly.

This article is about those decisions, in the order you have to make them, and about the one plan most teams skip until they need it.

What CRM migration is, and what actually breaks

CRM migration is the transfer of an organisation’s customer records and the logic around them from one platform to another. In practice it is four separate projects wearing one name, and they carry very different risk.

The object model is how each system represents people, companies, and revenue. The field inventory is every property attached to those objects. Historical data is the activity trail: emails, calls, tasks, stage changes. Automation is the workflows, assignment rules, and integrations that read and write those records.

Only the first two get planned properly on most projects. The transfer itself is a solved problem, which is exactly why it lulls teams into treating the whole thing as a technical task with a technical owner. It is a modelling task with an operational owner.

The automation layer is the one that ambushes people. Records can arrive perfectly and the system still behaves wrongly, because assignment rules fire on fields that now hold different values, lifecycle automation reprocesses ten thousand imported contacts as though they just arrived, and a webhook keeps posting to an endpoint that no longer exists. Every workflow in the target system should be switched off during the load and re-enabled deliberately, one at a time, with someone watching what each one touches.

The evidence that this goes badly is not hard to find. In Validity’s State of CRM Data Management survey of 602 CRM users and administrators across the US, UK, and Australia, 76% said less than half of their organisation’s CRM data is accurate and complete, and 37% reported losing revenue as a direct result of data quality. A migration inherits every one of those problems and then hard-codes them into a new system that nobody yet knows how to debug.

Four ways to move the data

Pick the transfer method after you have scoped the model, not before. The method constrains what transformations are possible mid-flight, and that is the only dimension that matters here.

Most mid-market teams end up on a dedicated tool for the bulk objects and a handful of custom scripts for the awkward ones. That hybrid is normal and worth planning for rather than discovering.

Reconcile the object model before you map a single field

Object mapping is the exercise of deciding which entity in the new CRM represents each entity in the old one. Do this before field mapping, because a field map built on the wrong parent object is wasted work you will not notice until reporting breaks.

Take the most common migration pair, Salesforce to HubSpot. In Salesforce, a person who has not been qualified is a Lead: a standalone record with no Account attached. When they qualify, the convertLead call splits that single record into an Account, a Contact, and usually an Opportunity. One row becomes three, and the pre-conversion history sits on a record that is now closed.

HubSpot models this differently. Its CRM object reference lists Contacts as object type 0-1 and Companies as 0-2, with a separate Lead object at 0-136 representing people who have shown interest but are not yet worked. So you have a genuine choice, and it is not a technical one.

The principle generalises past this one pair. Every CRM encodes an opinion about when a person becomes a company’s problem and when interest becomes revenue. Two systems rarely hold the same opinion, and the migration is where the disagreement surfaces.

Write the object decisions down as prose before anyone opens a mapping spreadsheet. If you cannot explain in a sentence why an unconverted lead becomes what it becomes, the field map underneath it is guesswork.

Custom objects and association cardinality

Custom objects look like the hard part and usually are not. Their fields copy across without much argument. What breaks is cardinality: how many records on one side may attach to how many on the other.

A source system that lets a subscription record attach to exactly one account, migrated into a system where the equivalent object attaches to many, will import without a single error and quietly produce revenue reporting that double-counts. The reverse case is worse: a many-to-many relationship collapsing into one-to-many silently drops every association past the first, and row counts still reconcile because the records themselves all arrived.

List every custom object with its association type on both sides before the load, and validate associations separately from records. Counting rows tells you the objects landed. Only counting associations tells you the model landed.

Deduplicate in the source system, not after cutover

Deduplication before a migration means resolving duplicate records in the CRM you are leaving, while it is still the only system anyone writes to. This ordering matters more than the matching logic itself.

Merge after cutover and you are merging records that have already accumulated new activity: a call logged Tuesday, an email thread started by a rep who did not know a second record existed, a deal attached to the wrong contact. The merge now has to decide which of two live histories survives. Merge before, and you are resolving records that only carry the past.

The second reason is that survivorship rules differ between platforms. The old system’s idea of which value wins on a merge is not portable, so a duplicate pair you leave for the new CRM to resolve will be resolved by rules you have not tested.

Choosing survivorship rules

Survivorship deserves its own decision, made once and written down. For each field, which record’s value wins: the most recently modified, the most complete, the one from a verified source, or the one on the record with the open deal? Those four rules disagree constantly, and picking per-field is the difference between a merge that improves the data and one that averages it into something nobody recognises. The account owner and the email address usually want different rules, and defaulting both to “most recent” is how a live opportunity ends up assigned to someone who left.

Run the matching pass and the merge as a distinct project phase with its own sign-off. The mechanics of choosing match keys and deciding which record survives a merge deserve more room than a migration plan usually gives them, and getting the survivorship rules wrong quietly destroys data that the import will then faithfully carry forward.

If the source is Salesforce, the choice between native duplicate management and a paid tool changes what is realistic in the time you have. Native rules catch exact and near-exact matches on standard fields, while the dedicated Salesforce deduplication tools handle fuzzy matching and bulk merge at volume, which is the difference between a two-week cleanup and a two-month one.

Volume is also where teams misjudge capacity. A cleanup that looks like a fortnight of admin work often is not, and it competes directly with the migration build. Deciding early whether to bring in outside help for the cleansing pass or absorb it internally keeps that from becoming the reason the cutover date slips.

Cut the field inventory instead of mapping it one to one

A field audit is the review of every property on every object to decide whether it moves, merges into another field, or dies. Run it as a deletion exercise, not a mapping exercise, because the default of mapping everything is what carries a decade of accumulated mess into a system that was supposed to be clean.

Three questions settle almost every field:

1. What is the fill rate? A field populated on 4% of records is not a field, it is a note somebody once took.
2. When was it last written to? Not last read, last written. A property that has not been updated in eighteen months is describing a process nobody runs.
3. Who consumes it? Name the report, the workflow, or the person. If nobody can, it does not move.

This is the one moment when deleting a field is politically cheap. Nobody defends a field during a migration the way they defend it during a normal cleanup, because the framing has changed from “we are taking something away” to “we are choosing what to bring.”

A migration that maps every field one to one has not migrated anything. It has relocated the problem and reset the clock on fixing it.

Surviving fields still need a shape. Picklist values, country and state formats, job titles, and phone formats all arrive from the old system in whatever variety accumulated there, and the load is the last easy moment to impose a single convention. Settling the naming and normalisation rules each field will follow before the mapping is signed off keeps the new CRM from inheriting six spellings of the same industry value.

Set a historical activity window before you scope the load

Historical activity is the log of emails, calls, meetings, tasks, and stage changes attached to your records. It is almost always the largest object by row count and the smallest by read rate, which makes it the single most useful thing to scope down.

The instinct is to bring everything, on the reasoning that storage is cheap and someone might need it. Storage is cheap. Migration time is not, validation time is not, and a new CRM whose activity timeline is 80% noise trains reps to stop reading timelines at all.

Twenty-four months is a starting position, not a rule. Match it to your actual sales cycle: if deals routinely take fourteen months, a twelve-month window cuts the history of live opportunities in half.

There is also a legal argument for the archive route rather than the migrate-everything route. GDPR Article 5 requires personal data to be “adequate, relevant and limited to what is necessary” and kept no longer than the purpose requires. Copying nine years of contact activity into a new system because it was easier than deciding is difficult to defend as either. A migration is a good moment to give that data a retention period instead of a new home.

Sequence the cutover in stages with gates you can measure

A staged cutover is a migration run in phases with a defined freeze, a bulk load, a catch-up load, and validation gates between each, rather than a single overnight switch. Stage it because a big-bang cutover gives you no point at which you can stop and still be safe.

The freeze window

The freeze is the period when the source CRM becomes read-only. It exists so that the data you extract is the data you load, and its length is the real constraint on the whole project: every hour of freeze is an hour reps cannot log activity.

Announce the freeze twice, enforce it with permissions rather than goodwill, and give reps a written place to park anything urgent. A freeze that depends on people remembering not to type is not a freeze.

The delta load

The delta load catches whatever changed between the last full extract and the freeze. Run the full extract days ahead so the bulk of the volume moves while the system is still live, then move only the changed records during the freeze itself. This is what turns a 40-hour outage into a 6-hour one.

Integrations and permissions

Integrations are the part of the cutover with the widest blast radius, because they touch systems outside the project’s control. Build an inventory before the freeze: every tool that reads from or writes to the CRM, what it does, who owns it, and what happens if it silently stops for a day.

The failure mode is rarely a loud error. It is a form handler still posting to the old CRM’s endpoint for two weeks while marketing wonders why lead volume dropped, or a billing sync writing to record IDs that no longer resolve. Record IDs almost never survive a migration, so anything that stores a CRM ID on its own side needs re-keying, not just re-authenticating.

Permissions need the same treatment and usually get less. Role hierarchies, territory rules, field-level security, and sharing settings do not translate between platforms, and the safe default of granting broad access “for now” tends to become permanent. Rebuild the permission model from what each role actually needs, and audit it a week after go-live rather than at the end of the project when everyone has moved on.

Validation gates

Validation is comparing what arrived against what should have arrived, using thresholds agreed before the load rather than judgement on the night. Count records per object, then check relationships, then spot-check values.

The word doing the work there is eligible. If you excluded ownerless tasks and pre-2024 activity, the source number in that calculation is the filtered count, not the raw one. Teams that compare against raw totals spend cutover night investigating a variance they created deliberately three weeks earlier.

Agree the acceptable variance per object in advance, and set it against a defensible target rather than a number invented at 2am. Deciding what completeness and duplicate rates are actually achievable before the load gives the go/no-go call something to reference.

That final step is the one teams cut when the schedule tightens, and it is the one that catches the errors validation scripts are structurally unable to see.

Write the rollback plan first, and know when it expires

A rollback plan is the documented procedure for returning to the source CRM as the system of record, including what gets lost when you use it. Write it before the first import, because writing it forces you to discover how narrow the window really is.

Here is the part that surprises people. Rollback is not a technical capability you either have or lack. It is a time-limited one, and the clock starts the moment a user creates or edits a record in the new CRM. Restore the old system after that and every one of those writes is gone, because they never existed in the source.

That gives you three postures, and the plan should name which one applies at each point in the schedule:

• Roll back when a structural defect affects most records across an object, and it was caught before users started writing. Example: every parent-child account association is missing.
• Fix forward when the defect is bounded to one field or object and can be re-loaded in place. Example: one picklist mapped to the wrong values. This is the right answer far more often than teams expect.
• Neither once meaningful new-system activity exists. At that point you are repairing in place, and the plan should say so out loud rather than implying a safety net that is already gone.

The rollback document itself is short. Who declares it, what the criteria are, who re-enables write access in the source system, what happens to anything created in the new CRM in the meantime, and who tells the sales team. Four hours of writing, and it is the only artefact in the project that is worth having and never using.

Set the expiry date in the plan as a date, not a feeling. “Rollback available until Thursday 18:00” is a decision the team can act on. “We could probably roll back if we had to” is not.

The first two weeks after go-live

What follows the expiry is the part worth staffing properly. For the first two weeks the migration team stays assigned to the migration, with a single named channel where users report what looks wrong and someone triages within the hour. Most of what arrives will not be data defects at all: it will be reps looking for a view that moved, or a report whose filter now references a field that was deliberately cut. Those are training issues wearing the costume of data issues, and the only way to tell the difference quickly is to have the people who made the mapping decisions still in the room.

Keep the source CRM in read-only mode for a quarter rather than decommissioning it at go-live. It costs one more billing cycle and it settles arguments that would otherwise be unresolvable, because the question “was this wrong before we moved, or did we break it?” comes up more than anyone expects.

Frequently Asked Questions