Playbook
Legacy Modernisation Without Downtime (Strangler Fig)
How to replace a monolith slice by slice while it keeps serving traffic — the pattern, the order, and how to know a slice is safe to cut over.
A big-bang rewrite fails for the same reason every time: the old system is the specification, and nobody has read all of it. The strangler-fig pattern avoids that by never asking you to.
The idea
Put a routing layer in front of the monolith. Build one new slice behind it. Send a little traffic to the new slice, then all of it, then delete the old code path. Repeat. The old system keeps serving throughout, and each step is individually reversible.
Which slice to take first
- Not the most painful part — the most isolated part. You are proving the mechanism, not fixing the worst thing.
- Something with clear inputs and outputs: notifications, PDF generation, a read-only report.
- Something you can compare — run old and new on the same input and diff the results.
How we know a slice is safe
| Stage | Traffic to new slice | Exit condition |
|---|---|---|
| Shadow | 0% (runs in parallel, results discarded) | Outputs match for a week |
| Canary | 5% | No new errors, latency within budget |
| Majority | 50% | Stable for several days |
| Cutover | 100% | Old path deleted, not just disabled |
What it looks like in practice
For a mid-size bank we re-platformed a .NET monolith this way. No outage window was ever used, and at every point in the project there was a working system in production. The order was: reporting first, then documents, then the customer-facing reads, and only last the transactional core.
If your problem is version age rather than architecture, an upgrade is cheaper and quicker than modernisation. We will say so if that is the case.
Questions
How long does modernisation take?
It runs slice by slice, so it is measured in sprints rather than a single date. Modernisation starts at $999 and is quoted per slice after a review — you can stop between slices with a working system.
Is a rewrite ever the right answer?
Occasionally — when the old system is small, well understood, and the platform is genuinely dead. For anything business-critical and undocumented, incremental replacement wins.
