Most modernisation guides organise around this taxonomy and then recommend whichever option the author sells. The taxonomy itself is genuinely useful, so it is worth setting out honestly — including where our own preferred answer is the wrong one.
The seven
| Approach | What changes | Relative cost | What it buys |
|---|---|---|---|
| Rehost | Infrastructure only | Lowest | Off dying hardware. Nothing else. |
| Replatform | Runtime, minimal code | Low | Supported stack, some operational gain |
| Refactor | Code, not structure | Medium | Maintainability; change gets cheaper |
| Rearchitect | Structure | High | Independent scaling and deployment |
| Rebuild | Everything | Highest | Exactly what you specify — if you can specify it |
| Replace | The system itself | Varies | Someone else's maintenance burden |
| Encapsulate | Nothing inside | Low | An interface; buys time and optionality |
Where each genuinely fits
Rehost
The data centre contract is ending or the hardware is unsupported, and the application is fine. Do this, take the win, and stop. Rehosting is frequently derided as "lift and shift" by people selling something more expensive; when the problem is genuinely the tin, it is the correct answer.
What it does not do is make anything cheaper to change. If the pain is change velocity, rehosting will not touch it.
Replatform
Same code, supported runtime — an unsupported database version to a current one, an application server to a container. Modest effort, real operational benefit, no structural change.
Refactor
Worth it when the system is structurally sound and simply hard to work in. It is also the approach most likely to be quietly abandoned, because it produces no visible feature and competes with the roadmap every sprint. Fund it explicitly or it will not happen.
Rearchitect
The monolith genuinely cannot scale or deploy in parts, and that is measurably costing you. The caution: much of what gets rearchitected did not need to be. Breaking a system apart adds network calls, distributed failure and operational complexity, and it is only worth it where the coupling is the actual problem.
Rebuild
Highest cost, highest risk, and the one most likely to be cancelled at eighty per cent. It is right when the system is small enough to redo in months, when the platform is genuinely dead, or when the business process is being deliberately replaced too — so parity with old behaviour is not the goal.
Where none of those hold, a rebuild is usually an incremental migration that has not admitted it yet.
Replace
A packaged product covers the need. Run the fit-gap honestly and count what needs customising rather than configuring — a short list means buy, and the cheapest modernisation is the one someone else maintains.
Encapsulate
The most underrated of the seven. Leave the system running, put a documented interface in front of it, and point everything else at that interface.
It changes nothing inside and buys a great deal: the rest of the estate stops depending on internals, integration stops being bespoke each time, and — crucially — you can now replace what is behind the interface incrementally without anything downstream noticing.
Choosing, per system
Four questions, applied to each system rather than to the programme:
- What is the actual pain? Hardware, cost, change velocity, scaling, or risk. Each points somewhere different, and "the system is old" is not a pain.
- Can it stop trading? If not, anything requiring a single cutover is off the table.
- Is the behaviour documented? If it exists only in code, rebuild is far riskier than it looks, because the specification is the thing you do not have.
- Is there an external date? An end-of-support or regulatory deadline removes options and should be worked backwards from.
A large estate will produce different answers for different systems. Treating modernisation as one decision is how organisations spend rebuild money on systems that needed rehosting.
The sequencing strategy that ties them together
The strangler pattern is not an eighth option. It is how you apply several of these in order on a system that cannot stop: encapsulate first so the estate stops depending on internals, then rearchitect or rebuild capability by capability behind that stable interface, then decommission what is left.
Its value is not elegance. It is that the work can be stopped at any point and still be worth something — each capability moved is value delivered and risk retired. A rebuild cancelled at eighty per cent is worth nothing at all.
The uncomfortable summary
The most common mistake is choosing an approach that is more expensive than the pain justifies — usually rebuild, usually because "the system is old" got treated as a diagnosis rather than a symptom.
Name the pain first. Several of these seven are cheap, and one of the cheap ones is often the right answer.