Every organisation has one: the system nobody wants to touch, that everything depends on, that leadership periodically decides to "finally sort out". The conversation that follows usually jumps straight to the most dramatic option — replacement — and then stalls, because the price is unthinkable and the risk is worse.
Why "just replace it" keeps failing
The stall is avoidable. Modernise, wrap and replace are not competing ideologies; they are tools with measurable selection criteria. The right answer for a given system falls out of five factors — and for most critical estates it is a combination, sequenced over time, rather than a single verdict.
Large rewrite programmes often fail through a recurring set of risks. The scope is defined as "everything the old system does" — a specification nobody actually possesses, because decades of behaviour live in code, workarounds and the heads of its operators. The old system keeps changing while the new one is built, so the target moves. And the business case assumed a switch-over date, so every delay is visible and political.
None of this means replacement is always wrong. It means replacement is a migration architecture problem, not a procurement decision — and that the failure begins the moment the question is asked as "old or new?" instead of "what has to change, at what risk, in what order?"
The five factors, scored with evidence
Five properties of the system decide which modes are even available:
- Business criticality — what happens in the hour the system misbehaves? The higher the cost, the more the answer must preserve production continuity.
- Change frequency — how often does the business need this system to change? A stable system under low change pressure earns different treatment from one blocking a roadmap.
- Coupling — how many other systems reach into it, and how deeply? Coupling determines whether any boundary can be drawn without an archaeology project.
- Operational risk — how well is it understood? Monitoring, tests, documentation, and whether the people who know it are still in the building.
- Migration cost — the honest total: engineering, data migration, parallel running, retraining, and the opportunity cost of the team it consumes.
Score these with evidence — dependency mapping, change logs, incident history — rather than impressions. The scoring exercise itself routinely corrects the room's assumptions: the system "everyone" changes constantly turns out to change twice a year; the "well-understood" one has no tests and one remaining expert.
Modernise: evolution in place
Modernising means improving the system where it stands: reducing coupling, adding tests and observability, modularising the internals, upgrading the platform underneath it. It fits systems that are highly critical and deeply coupled — where any boundary is expensive — but whose functionality is fundamentally right.
Its virtue is that every step is production-safe and independently valuable. Its limit is that it cannot change what the system fundamentally is; if the data model or core assumptions are wrong for the business, in-place work polishes the wrong thing.
Wrap: stabilise the boundary, buy time
Wrapping puts a deliberate interface — an API layer, an event stream, an anti-corruption boundary — between the legacy system and everything else. The internals rest; the estate around them gets a clean contract to build against.
Wrapping fits when new capabilities are urgent but the core cannot be safely touched yet. It is also the natural first move of a staged replacement: once consumers talk to the boundary rather than to the internals, what sits behind the boundary can change without them noticing. Its danger is permanence — a wrapper installed as "phase one" has a way of becoming the architecture. A wrap decision should carry a date on which it is reviewed.
Replace: justified, and sequenced
Replacement is justified when the five factors align: functionality fundamentally wrong for the business, high change pressure, and a migration cost that — fully totalled — beats years of fighting the old system. Even then, the credible version is incremental: carve out one capability at a time behind the wrap boundary, route traffic to the new implementation, prove it in production, retire the old path, repeat. The strangler pattern is not caution for its own sake — it converts one unsurvivable risk into a series of survivable ones, each with a rollback.
The version to refuse is the big bang: years of parallel build, one heroic cut-over weekend, and a scope defined as feature parity with a system nobody fully knows.
Combining modes across one estate
Real estates rarely get one verdict. A common shape: wrap the core system now to unblock the roadmap; modernise the components that are staying (tests, observability, decoupling); replace the two modules where the data model is genuinely wrong — through the boundary, one at a time. The decision is per capability, not per system, and the sequence is chosen by risk and business impact.
A worked matrix
For each capability of the system, score the five factors and ask three questions in order: Is the functionality fundamentally right? If yes — modernise in place. Is the boundary drawable at acceptable cost? If yes — wrap, and reassess behind it. Does honest migration cost beat the cost of keeping it? Only if yes — replace, incrementally, behind the wrap.
Written down, the matrix does something valuable beyond the decision itself: it turns "we should finally sort out the legacy system" into a sequenced engineering roadmap that survives budget review — because every step justifies itself.
Three-question decision test
- Is the functionality fundamentally right for the business?
- Is the boundary drawable at acceptable cost?
- Does honest migration cost beat the cost of keeping it?