The Strangler Fig Pattern: Modernizing Legacy Systems Without a Big-Bang Rewrite
July 31, 2026 · Next Wave Intelligence
"Let's just rewrite it" is one of the most expensive sentences in enterprise software. Full rewrites take longer than estimated, freeze feature development for months or years, and routinely get cancelled halfway through once the business realizes it's funding two systems with no clear date the old one goes away. There's a better default.
What the strangler fig pattern actually is
The name comes from strangler fig trees, which grow around a host tree, gradually taking over its structure until the host is no longer needed. Applied to software, it means building the new system around the edges of the old one — routing a small slice of traffic or functionality to the new implementation, verifying it works, then expanding — until the legacy system has nothing left to do and can be switched off.
The business keeps running on a working system the entire time. There's no cutover weekend, no all-hands freeze, and no moment where everything is broken until the rewrite is "done."
Why this beats a full rewrite in practice
- You ship value continuously. Each migrated slice is a real, deployed improvement — not a feature the business waits a year to see.
- You can stop or reprioritize at any point without losing the work already done, because each migrated piece is already live in production.
- Risk is contained to one slice at a time instead of the entire system going live at once on a single cutover date.
- You learn the legacy system's real behavior as you go — including the undocumented edge cases a big-bang rewrite would only discover after launch, when it's expensive to fix.
How we sequence it
Start with the piece that's lowest-risk but still meaningfully valuable — not the hardest problem, and not something trivial enough to be pointless. Put a routing layer in front of both systems so traffic can be shifted deliberately, ideally with the ability to roll back instantly if something's wrong. Migrate that first slice completely, including its data, then verify it in production under real load before touching the next piece.
Repeat that loop — pick the next slice, route to it, verify, expand — until the legacy system's surface area has shrunk down to nothing worth keeping alive.
Where this pattern breaks down
It doesn't work well when the legacy system is a true black box with no clear seams — no way to intercept and redirect specific functionality without touching everything at once. In those cases, the real first project isn't migration at all; it's adding the observability and interfaces needed to create seams to strangle in the first place. That's a smaller, cheaper project than a rewrite, and it makes everything after it safer.
The honest tradeoff
A strangler fig migration takes longer in calendar time than a rewrite's best-case estimate — because you're running two systems in parallel for a while and being deliberate about each slice. What you get in exchange is a migration that almost never gets cancelled halfway through, because the business never stops getting value out of it.
We go deeper on how we scope these migrations on our Enterprise Modernization page, or get in touch if you're looking at a legacy system that needs this kind of approach.