In the rainforests of Central America and Southeast Asia grows a tree that doesn't play by the usual rules. A strangler fig starts life as a tiny seed, dropped by a bird into the branches of another, older tree, high above the ground. It never sprouts from soil. Instead it sends thin roots downward, wrapping around the host tree's trunk as they reach for the ground below. Over years those roots thicken into a woody lattice that gradually encases the host completely. Eventually the original tree dies and rots away inside its new shell, leaving a tree-shaped tube of fig roots standing on its own — doing exactly the job the host once did, holding up a canopy of leaves, reaching for sunlight — without the forest ever losing a tree to do it.
It's an odd image to bring into a conversation about legacy software, but software architects have borrowed it for a reason: it describes, almost exactly, the safest way to replace an old system. Not by tearing it down and starting from a blank page, but by growing the replacement around it, piece by piece, until the old one can finally be removed with nobody noticing the moment it happened.
Why the big-bang rewrite fails so often
The obvious way to replace an aging system is to build a brand-new one from scratch and switch over on a chosen day. It rarely works out that way, and the reasons are structural, not about effort or talent.
First, the business can't stop running for the months, or years, a full rewrite takes. Orders keep coming in, support tickets keep arriving, and someone has to keep the old system alive and correct the entire time the new one is being built — which means the old "temporary" system quietly becomes a permanent, double-maintained system for the length of the project.
Second, the old system doesn't sit still while you rebuild it. The business keeps changing, which means requirements keep changing, which means the rewrite is chasing a moving target the whole way. By the time the new system is "done," it's being measured against a version of the business that no longer exists.
Third, and most dangerous: a big-bang rewrite validates almost nothing until the very end. Every assumption, every edge case, every quirky bit of behavior the old system handled correctly sits untested in production until cut-over day, when all of it has to work at once, for every user, with no gradual exposure to real traffic beforehand. That's an enormous amount of risk concentrated into a single afternoon.
How the strangler approach works, step by step
The strangler fig pattern — sometimes just called an incremental migration — avoids all three problems by never having a cut-over day at all.
- Put a new app in front. You build a thin new application — in this context, usually ASP.NET Core — that receives every incoming request first, before the old system ever sees it.
- Forward what isn't migrated yet. For any page or route the new app doesn't yet handle, it simply passes the request straight through to the old system behind it, which responds as it always has.
- Migrate one piece, in production, under real traffic. You pick a single page or feature, rebuild it inside the new app, and point that one route to the new code instead of forwarding it. Everything else keeps working exactly as before.
- Repeat, ordered by risk and value. You move through the application page by page, usually starting with something low-risk to prove the setup, then working toward whatever matters most to the business.
- Retire the old system once it's empty. When every route has been migrated and the old application is handling zero live traffic, you turn it off. There was never a day everything changed at once — just a long series of small, already-proven changes.
A concrete example
Picture a company running its entire public site on an aging ASP.NET WebForms application — the kind with a page lifecycle and server controls that, as I've written about separately, have no direct equivalent in modern .NET and have to be rebuilt rather than converted.
We don't rewrite the whole site. We build a new ASP.NET Core app and put it in front of the old one: every request arrives at the new app first, and for now, the new app forwards all of them straight to the WebForms system behind it. Nothing changes for users yet.
Then we migrate the login page — a good first candidate, foundational but well understood — into the new app, and stop forwarding that one route. Users logging in now hit new code; everyone else is still on the old system, unaware anything changed. Next comes the product catalog, then account settings, then checkout, each one tested in production, under real traffic, before the next one starts. The old WebForms app shrinks a little with each release, handling fewer and fewer routes, until one day it's handling none, and we switch it off.
What this buys you that a rewrite doesn't
Every step in this approach is validated with real users and real data before the next one begins, instead of all validation happening at once on a single, high-stakes day. If priorities shift halfway through — and on a long project, they usually do — you can pause after any migrated page with a fully working system on both sides of the line, not a half-finished rewrite nobody can ship. And because each release is small and bounded, a mistake in one migrated page is a bug to fix, not a crisis affecting the whole business.
It's also, frankly, better for morale. A team that ships something real every few weeks stays confident and visible to the business. A team that disappears for a year to rebuild everything is asking for trust it hasn't earned yet, no matter how good the work turns out to be.
The tree, eventually, stands alone
That's the whole idea behind the name. The strangler fig spends years looking like it's just wrapped around another tree — until one day the host is gone, and what's left was built, patiently, to stand entirely on its own. Nobody watching the forest sees the exact day it happened, because there wasn't one.
That's what a well-run legacy migration looks like from the outside too: not a dramatic cut-over, just a long series of small, boring, successful days, until the old system quietly isn't there anymore.