Industry studies put the failure rate of major ERP and CRM migrations somewhere north of 50% — by which they usually mean “over budget, late, or didn't deliver the promised benefits.” The interesting part is why. It isn't usually the new system being wrong. It's that cutover is treated as a single Big Day, and the business turns out not to cleanly snap from System A to System B at 3am on a Saturday in September.
Big-bang cutovers fail because reality is asymmetric: System A has been accumulating undocumented edge cases for ten years, and the team that handles them all left during the migration project. A staged approach — slower, more disciplined, less dramatic — has a meaningfully higher hit rate. Here's how to run one.
Step 1: Decide what “migrated” means
Different teams will answer this very differently if you don't define it up front. A useful working definition:
Migration is complete for a domain when every business transaction in that domain is initiated, recorded, and reported in the new system, and the corresponding records in the old system are either frozen, archived, or removed.
Notice three things in that sentence: it's per-domain (not whole-business), it covers the full transaction lifecycle, and it includes the disposition of the old data. Each of those is a decision the project owes itself before any technical work starts.
Step 2: Split the world into domains and pick the order
Treat the legacy system as a collection of independent domains (customers, orders, billing, inventory, financials, reporting) rather than one big monolith. Each domain has its own data, process, and stakeholders. The order you migrate them in matters more than the speed of any individual migration.
Three useful sequencing principles:
- Migrate read-heavy domains before write-heavy ones.A reporting layer can run on a snapshot for a while; transactional workflows can't.
- Migrate dependents before dependencies.If billing depends on the customer master, you can't fully migrate billing before customers are stable in the new system. Sort by dependency graph.
- Front-load the riskiest domain.Counter-intuitive but right. The domain you're most uncertain about is the one whose unknowns should surface earliest, when there's still time to react. Saving it for last is how programmes blow up at month nine.
Step 3: Build a bridge, not just a load
The defining feature of staged migration is that both systems are live simultaneously, sometimes for months. That means data has to flow between them — a bridge, usually built as an iPaaS integration or a small custom service, that keeps the two systems consistent during the staged period.
The bridge handles four things:
- Initial backfill. A one-time pass that loads historical data into the new system in the right shape.
- Incremental sync. Any change in the source of truth flows to the secondary system within an agreed SLA (minutes for transactional, hours for reporting).
- Conflict resolution.When the same record is edited in both systems (which will happen), there's a documented rule for which wins. Usually: whichever system is designated as the system of record for that domain at that moment.
- Reconciliation. A daily pass that verifies the two systems agree, with discrepancies surfaced for human review.
The bridge is the single most important piece of the project. It gets less attention than the new system's configuration, and more programmes have failed at the bridge than at the configuration.
Step 4: Flip system of record per domain, not all at once
For each domain, there's a moment when the new system becomes the source of truth and the old system becomes a read-only secondary. That moment is a per-domain decision, not a global event.
A typical sequence for a mid-size business migrating an ERP:
- Month 1–2: reporting and analytics flip first. Low risk because nothing transacts.
- Month 3–4: customer master and product catalog flip. These are reference data, edited rarely.
- Month 5–7: orders flip. The big one. Validates everything upstream.
- Month 8–9: billing and revenue recognition flip. Usually last because finance needs longer parallel runs to trust the numbers.
- Month 10: close the bridge, decommission the legacy system.
The numbers vary by business, but the principle holds: each domain gets its own cutover, and the project carries fewer eggs in any one basket.
Step 5: Keep an honest backout plan
Every per-domain cutover has a backout plan that's actually executable. Not the polite kind that lives in a binder; the real kind, with named steps and rehearsed timing.
The two questions a backout plan must answer:
- How quickly can we revert the bridge to make the old system the source of truth again, if the new one misbehaves?
- What data is at risk of being lostin the window between cutover and backout? Usually transactions created during the “new system live” window. Plan how to replay them.
Two days into a cutover is not the moment to figure this out. Rehearse it before each per-domain flip, on a non-production copy. The cost is one day per domain; the upside is being able to actually use the backout if you need it.
What we won't recommend
- Big-bang weekend cutovers. Tempting because they end the project faster on paper. The hit rate is poor and when they fail, they fail in dramatic ways.
- “Migrate everything as-is”.Tempting because it sounds safer (no scope creep). Usually carries forward fifteen years of accumulated technical debt into a system that wasn't designed to absorb it.
- Building the bridge as a throwaway.The bridge is the project. Treat it as production code: tested, documented, monitored. It'll run for longer than anyone plans.
The hardest part is the political part
Most migration programmes have at least one team that quietly wants the old system to stay. Maybe they built it. Maybe they only know how to use it. Maybe their power within the company derives from being the person who can answer questions about it. That gravitational pull is a real force, and it kills more migrations than data quality does.
The structural defence: name the owner of the migration explicitly, separate them from anyone whose career is tied to the legacy system, and give them direct executive air cover for the duration. Without that, the staged approach turns into a permanent parallel run — which is the most expensive possible outcome.
How long should this take?
For a mid-size business (100–500 employees) migrating an ERP or CRM with five to seven domains, expect 9–14 months from kickoff to legacy decommission. Anything faster is probably skipping steps that catch up with you later. Anything slower is usually scope creep or political drag.
The investment is real. So is the failure mode of doing it the other way — every team has stories of weekend cutovers that ended with rollbacks at 3am and a week of manual data repair. Staged migrations are slower, less heroic, and meaningfully more likely to finish.