Modernise a legacy ERP in waves that each deliver working software to production, never in a single cutover. The big-bang replacement fails for a structural reason, not a technical one: it defers all risk to one date, by which point the people who understood the original decisions have moved on and the business has changed underneath the design. A wave-based approach — strangling functions out one at a time behind a stable interface — keeps production running throughout and lets you stop, re-sequence or abandon a wave without losing the programme.
This is the playbook we use with manufacturing, energy, government and distribution clients across the Gulf and India, where the ERP frequently cannot stop for even a weekend.
Why big-bang cutovers fail
Three reasons, in order of how often they are the actual cause:
- Undocumented behaviour. Two decades of customisations, interfaces and workarounds encode business rules nobody has written down. Discovery finds most of them. Production finds the rest, at the worst moment.
- The business does not stand still. A three-year programme is designed against a business that will not exist by the time it lands. Requirements drift, and the response is scope change on a plan with no slack.
- No safe stopping point. Value arrives only at the end, so pausing means writing off everything spent. That pressure keeps failing programmes alive well past the point of evidence.
Wave-based delivery addresses all three: each wave is small enough to understand, short enough to survive business change, and complete enough that stopping afterwards still leaves you better off.
The playbook
Wave 0 — Establish the seam
Nothing is migrated in Wave 0. You build the boundary through which everything else will move: an integration layer in front of the legacy ERP that becomes the only sanctioned way to read or write its data.
This is the strangler-fig pattern applied to ERP. Every consumer is redirected through the seam while the legacy system still serves every request. Nothing changes functionally — and that is the point. When later waves move a function, consumers do not know.
Deliverables: the interface layer, an inventory of every consumer and integration, and a data dictionary for the entities crossing the seam. That inventory is usually the first time anyone has a complete list, and it routinely uncovers integrations nobody remembered.
Wave 1 — Move read paths first
Reporting, analytics and read-only lookups. These carry the lowest risk because they do not mutate state and can be reconciled directly against the source. Replicate the data you need into a modern store, point read consumers at it, and verify continuously.
Two things get proved here that matter far more than the reporting: your replication pipeline and your reconciliation method. If you cannot demonstrate the copy matches the source, you are not ready to move writes.
Wave 2 — Move a bounded write function
The first genuine migration. Choose a function that is high volume enough to be meaningful, but with the fewest dependencies — often procurement approvals, asset registers or a specific master data domain rather than anything touching finance close.
Run it in parallel: both systems process, outputs are compared, legacy remains authoritative until the comparison is clean for an agreed period. Parallel running is the single most effective de-risking technique available, and the one most often cut when timelines slip.
Waves 3 to N — Sequence by dependency, not by ambition
Order the remaining functions by dependency depth, not by which module the executive sponsor is keenest to replace. Each wave repeats the same shape: seam already exists, replicate, parallel run, compare, cut over, decommission.
Decommissioning matters. A wave that leaves the legacy path running "just in case" has added a system rather than replaced one. Each wave should end with something switched off.
Final wave — Retire the core
By the time the core is addressed, most functions have already moved and the remaining surface is small enough to handle conventionally. This is the opposite of the big-bang shape, where the core is attacked first and everything depends on it.
Sequencing rules that hold up
- Never migrate a function you cannot reconcile. If you cannot prove old and new agree, you cannot safely cut over.
- Prefer functions with a natural quiet period for the first write migration — the cutover window is real, even if brief.
- Do not start with finance. It has the most dependencies, the least tolerance for discrepancy, and a statutory calendar.
- Treat master data as its own wave. It is the substrate everything else depends on, and doing it inside another wave hides its cost.
- Keep waves to a quarter or less. Longer, and business change outruns the design again.
What this looks like on a production line
For manufacturing and energy clients the constraint is not the ERP — it is that production cannot stop. That changes two things.
First, cutover windows are measured in hours during planned maintenance, which makes rehearsal non-negotiable. Every cutover is executed at least twice against production-like data before the real one, with the rollback path rehearsed as thoroughly as the forward path.
Second, the rollback decision needs a pre-agreed trigger and a named person empowered to make it during the window. Teams that leave this to be decided in the moment consistently push on past the point where rolling back was cheap — a failure of governance rather than engineering.
Cost and duration, realistically
Wave-based programmes look more expensive on the initial estimate because the seam is real work that a big-bang plan does not show. They usually cost less in total, for three reasons: parallel running catches defects when they are cheap; each wave's learning improves the next estimate; and there is no six-month stabilisation period after go-live, because there is no single go-live.
Typical shape for a mid-size enterprise ERP: Wave 0 in six to ten weeks, read paths in one quarter, then a quarter per functional wave, with several waves running concurrently once the pattern is established.
Conclusion
The choice is not between fast and safe. Big-bang is not faster — it defers all evidence of progress to a single date, and when that date slips there is no partial value to show for the spend.
Wave-based modernisation puts working software in production continuously, decommissions legacy incrementally, and gives the business a defensible point to stop at every quarter boundary. On a system the organisation genuinely cannot afford to break, that optionality is the whole argument.
Loyal Bytes runs ERP and legacy modernisation programmes for manufacturing, energy, government and distribution clients across the Gulf and India, including environments where production cannot pause. See our cloud and digital modernization practice or discuss your estate and sequencing.
Frequently asked questions
What is the strangler pattern for ERP modernisation?
An integration layer is placed in front of the legacy ERP so all consumers go through it, then functions are moved behind that boundary one at a time. The legacy system is gradually starved of responsibility rather than replaced in one event, and consumers are unaffected by each move.
How long does a wave-based ERP modernisation take?
For a mid-size enterprise, roughly six to ten weeks to establish the integration seam, a quarter for read paths, then about a quarter per functional wave, with waves overlapping once the pattern is proven. Total duration is often comparable to a big-bang plan, but value arrives throughout instead of at the end.
Can we modernise ERP without downtime?
Effectively yes for most functions, using parallel running and cutovers scheduled into existing maintenance windows. Some cutovers need a short window measured in hours; the way to make that safe is rehearsal against production-like data, including the rollback path.
Which module should we migrate first?
Not finance. Start with read-only reporting to prove replication and reconciliation, then a bounded write function with few dependencies — procurement approvals, asset registers or a master data domain. Finance has the most dependencies and the least tolerance for discrepancy.
Is wave-based modernisation more expensive?
It usually looks more expensive up front because the integration seam is visible work, and usually costs less in total. Defects surface while they are cheap, each wave improves the next estimate, and there is no lengthy post-go-live stabilisation because there is no single go-live.
What happens if we have to stop mid-programme?
That is the main advantage of the approach. Every completed wave has already delivered working software and decommissioned part of the legacy estate, so stopping leaves the organisation better off than before rather than with a half-built replacement.
