Every modernisation project starts with the same conversation. Someone in the room says “we just need a clean rewrite,” someone else says “we don’t have time for a clean rewrite,” and a third person — usually whoever has been there longest — says “we tried that in 2019.”
~ 7 MIN READ
The strangler pattern is what you do when none of those three positions is workable. You leave the old system running. You write the new one alongside it. You route requests from the old to the new, one slice at a time, until eventually the old one is doing nothing and you can switch it off.
That’s the theory. In practice there are four things nobody tells you.
The first slice is going to take three times longer than you planned
Doesn’t matter which slice. Pick the smallest, most isolated bounded context you can find — order status lookup, customer search, something boring. The first one is where you discover everything you didn’t know about the legacy. Undocumented stored procedures. A scheduled job nobody remembers writing that still runs every night. Two integration partners who agreed to a contract change in 2017 and never told anyone.
Budget for it. The first slice is your tax for never reading the legacy code in the first ten years it was running. After that, slices get faster.
Shadow mode is non-negotiable
Before you cut any traffic to the new component, run it in shadow mode. Both old and new receive the request. Only the old one’s response goes back to the caller. The new one writes its output to a log and you compare.
This sounds obvious. It is not optional. We had a case once where shadow mode was “too much effort to set up” for a small slice — pricing calculation, supposedly simple. The new code matched the old for 99.4 percent of cases. The 0.6 percent that didn’t were a specific volume-discount tier the new logic was off by one cent on. Six tenths of a percent times a hundred thousand orders a month is a lot of cent-by-cent invoice arguments. Caught in shadow, fixed in a day. Caught in production, you’re explaining to the CFO.
The data migration is the project
There’s a fiction in modernisation work that the application is the thing being replaced. It isn’t. The application is the easy part. The data is the project.
Legacy data has defaults that nobody documented. Workarounds that became contracts because they shipped to a client. Fields that used to mean one thing in 2010 and now mean three different things depending on which year the row was written. We had one case where the same column was used to mean “order status” for half the data, “shipping status” for a quarter, and “a comma-separated tag list” for the rest. Different teams over different years. All of it production.
Treat data migration as its own engineering project, with its own architecture decisions, validation tooling, reconciliation reports, and shadow-mode comparison against the legacy. Allocate at least as much time to it as to the application rewrite. If your plan doesn’t, your plan is wrong.
The rollback path matters more than the cutover
Strangler works because rollback is one configuration change away. The moment you’re committed — the moment you can’t switch back to the legacy in five minutes — you’ve lost the property that makes the pattern safe.
On the project that almost didn’t work, we hit a performance regression three weeks after cutover. The new component was slower under a specific tenant’s load profile. Not slow enough to fail SLAs but slow enough to be visible. Because we still had the legacy running in parallel, we flipped traffic back, fixed the issue without pressure, and re-cutover a week later. If we’d already decommissioned the legacy, that would have been three weeks of customer-facing performance problems.
Keep the legacy on warm standby longer than feels necessary. Decommissioning is the last step, not the first.
What this looks like, day to day
Most of the work is unglamorous. You build a routing layer — usually at the API gateway level. You add a feature flag for each slice. You write reconciliation reports that nobody reads until something disagrees. You spend more time talking to the legacy team than to the new-platform team, because they know where the bodies are.
The clients who survive modernisation projects are the ones who accept that the work is not exciting. It is patient, careful, and slow. The reward is that the business doesn’t notice when the switch happens — and that, frankly, is the entire point.