Somewhere in your organisation there is a slide deck proposing a two-year rewrite of the legacy system. It has a clean target architecture, a phased timeline, and a quiet assumption that the roadmap can hold its breath while the rewrite happens. It can’t. Rewrite plans rarely die of bad engineering — they die because eighteen months is longer than any budget cycle, and the first urgent feature that has to go into the old system anyway turns the plan into a stalled branch.
Why the two-year rewrite dies
The failure mode is structural, not a matter of effort. All the value lands at the end, so for the entire duration the business is paying for two systems and getting one. Risk accumulates instead of retiring: the big cutover at month twenty is the single riskiest deployment the company has ever attempted, performed by a team that has not shipped to production in two years. Meanwhile the old system keeps changing — a feature freeze never survives contact with a customer escalation — so the rewrite is chasing a target that moves. And when leadership or budgets shift, a half-finished rewrite with zero shipped value is the first thing cancelled.
Wrap, route, extract
The strangler pattern replaces the big bang with a sequence of small, boring moves. The mechanics have three verbs.
- Wrap — put a facade in front of the monolith: an API gateway, a reverse proxy, an anti-corruption layer. Nothing changes yet; you have simply created the one place where routing decisions live.
- Route — send all traffic through the facade. Now every capability of the old system has an address you control, and you can observe real usage per capability before touching any of it.
- Extract — pick one capability, rebuild it behind the facade, and flip its route to the new implementation. The monolith keeps serving everything else. Repeat until the old system is an empty shell, then switch it off — usually as an anticlimax.
Every step ships, every step reverses
Each extraction is a normal production release: reviewed, deployed, observed. Value arrives with the first slice, not at month twenty. Risk retires in increments the size of one deployment instead of accumulating into one terrifying weekend. And because every step is small, the programme survives interruptions — pause it for a quarter and you have a system that is simply partway better, not a dead branch.
What reversible means in practice
“Reversible” is a checklist, not a mood. A step qualifies when all of these hold:
- The cutover is a routing flag, not a code deletion — flipping traffic back to the monolith takes minutes and no deploy.
- The old path stays alive — monolith code for an extracted capability is removed only after the new path has run in production long enough to be trusted, not the day it launches.
- Shadow traffic before real traffic — the new implementation receives mirrored requests and its responses are diffed against the old one, so behaviour differences surface before customers do. Characterisation tests that pin the monolith’s current behaviour, bugs included, make this diff meaningful.
- Data has one owner at a time — either the old store stays authoritative with the new service reading through, or writes go to both until the numbers agree. A step that forks data ownership is not reversible, whatever the routing layer says.
The roadmap keeps moving
The quiet advantage of the pattern is sequencing. You do not extract in architectural order; you extract in roadmap order. The module the business needs to change next quarter is the module you strangle now — so the migration and the feature work become the same ticket, and the new capability is built once, in the new world, instead of twice. Capacity is split explicitly and openly: a standing share of the team on extraction, the rest on the roadmap, both shipping every sprint. Modernisation stops being the thing that competes with the roadmap and becomes the way the roadmap gets delivered.
We have run this discipline at application depth and at platform depth — the systems our group builds and operates end to end range from consumer products to a full OpenStack cloud implementation run as a PaaS, and the rule is the same at every layer: wrap the old thing, route deliberately, and never take a step you cannot walk back by lunchtime.
If you have a monolith and a roadmap that both refuse to wait, look at what we have built and run, or start with our dedicated teams — the first conversation is a technical call, not a sales call.