Why does the big-bang cutover keep failing?
The big-bang approach — freeze the old system on Friday, migrate over the weekend, everyone uses the new one on Monday — is attractive because it is simple to plan and it has a defined end date. It fails often enough that it deserves to be the exception rather than the default.
It fails because it concentrates every risk into one irreversible moment. Data problems, integration problems, training problems, and performance problems all arrive together, at the point of least available time, with no way back. And the rollback plan that looked adequate on paper usually is not, because by Monday afternoon real transactions exist in the new system that do not exist in the old one.
The alternative is not slower. It is the same total work, spread so that each piece can fail independently and be fixed while the business keeps running.
What does the strangler pattern look like for an ERP?
The strangler fig pattern — named for the plant that grows around a tree and gradually replaces it — is the standard approach to replacing a system you cannot switch off. Applied to an ERP, it looks like this:
- Put a routing layer in front of the old system. Initially it forwards everything unchanged, which means shipping it is a no-op and therefore safe.
- Pick the module with the clearest boundary and the least coupling — often procurement or a reporting surface, rarely finance.
- Build that module in the new system and route its traffic there, while continuing to write the results back so the old system's reports stay correct.
- Run both in parallel for a full business cycle and reconcile. Discrepancies at this stage are the whole point: they are the requirements nobody wrote down.
- Stop writing back, retire the old module, repeat.
How do you sequence the modules?
Sequence by coupling, not by importance. The module everyone wants replaced first is usually finance, and finance should almost always go last — everything posts to it, so moving it early means building temporary bridges to every module you have not migrated yet.
| Phase | Module | Why here |
|---|---|---|
| 1 | Reporting and analytics | Read-only. Proves the data pipeline and gives users something visibly better before anything risky happens |
| 2 | Procurement or CRM-adjacent modules | Loosely coupled, self-contained workflow, low blast radius |
| 3 | Inventory and operations | High value, moderate coupling, benefits most from the new system |
| 4 | HR and payroll | Self-contained but unforgiving — a payroll error is a trust event |
| 5 | Finance and the ledger | Everything posts here. Move it once the things that post are already moved |
What do you do about the data?
Data migration is where the schedule actually goes, and the reason is rarely technical. Moving rows is straightforward. Deciding what the rows mean is not.
A legacy ERP typically contains a decade or more of entries made under rules that changed, by people who left, into fields that were repurposed. Three suppliers that are the same company. A status code that meant one thing until 2019. Quantities in two different units in the same column. The new system's constraints will reject all of it, which is correct behaviour and feels like an obstacle.
Three things make this tractable. First, profile the data before committing to a date — count the duplicates and the constraint violations, and let the real number set the timeline. Second, decide explicitly how much history moves; five years of transactions in the new system with the rest in a read-only archive is a legitimate and much cheaper answer than migrating everything. Third, make the cleaning the business's work, not the vendor's — only your staff know which of the three supplier records is the real one.
How do you know a module is safe to cut over?
Parallel running is only useful if somebody is actually comparing the outputs, and the comparison has to be specific enough to fail.
Define the reconciliation before the phase starts: which reports, which totals, what tolerance, who signs. Closing balances, stock valuation, tax totals, and payroll gross-to-net are the usual candidates, and the tolerance for most of them is zero.
Then require the same result from both systems for one full cycle — a month for most modules, a quarter where statutory reporting is involved. A module that reconciles cleanly for a cycle is safe to cut over. One that does not is telling you something you need to hear before the old system is gone.
Keep the old system readable for a year after the last module moves. It costs very little, and the first time an auditor asks about a transaction from two years ago, it pays for itself.
Sources
- StranglerFigApplication — incrementally replacing a system in production — Martin Fowler
- Cloud design patterns — Strangler Fig, Anti-Corruption Layer, and routing — Microsoft Learn
- GST portal — statutory reporting continuity during a system change — Goods and Services Tax Network