Legacy Modernization without the big-bang risk
Move off aging systems incrementally — delivering value the whole way — instead of betting the business on a single rewrite.
Every aging system is doing two jobs at once: running the business, and quietly draining the budget that could improve it. The instinct is to “just rewrite it.” That instinct is usually how a one-year project becomes a three-year crisis. There’s a better way, and it starts with being honest about what the old system actually costs.
The hidden tax of legacy
Technical debt isn’t an abstraction — it has a line on the budget, even if no one writes it down. Stripe’s Developer Coefficient found engineers spend an average of 17.3 hours a week on maintenance, debugging, and managing technical debt — roughly a third of their time not building anything new. McKinsey, surveying CIOs at large firms, put the scale of accumulated tech debt at 20–40% of the entire value of the technology estate, with 10–20% of every new-product budget quietly diverted to paying it down.
At the extreme, you get the public sector: the US GAO found federal agencies spend about 80% of their ~$100B IT budget just operating and maintaining existing systems, some of them decades old — its 2025 review flagged critical systems ranging from 23 to 60 years old, several still running COBOL with a shrinking pool of people who can maintain them.
| What legacy costs | Figure | Source |
|---|---|---|
| Developer time lost to maintenance/debt | 17.3 hrs/week | Stripe, 2018 |
| Tech debt as share of tech estate value | 20–40% | McKinsey, 2020 |
| Federal IT budget spent just keeping the lights on | ~80% | US GAO, 2025 |
| Age of the oldest critical federal systems | up to 60 yrs | US GAO, 2025 |
The pattern is the same whether you’re a government agency or a growing company: the older the system, the more of your capacity it consumes, and the less you have left to compete.
Why the big-bang rewrite fails
The tempting move is to freeze the old system, build a shiny replacement beside it, and flip a switch. It almost never works, because while you spend a year (or three) rebuilding, the old system keeps changing, the requirements drift, and you deliver zero value until the risky cutover at the very end — if you reach it at all.
The strangler-fig pattern — named by Martin Fowler after the vines that grow around a tree until they replace it — inverts that risk. You put a façade in front of the old system, then migrate one capability at a time behind it. Each release ships real value; the old system shrinks until there’s nothing left to retire.
How the migration actually runs
A façade sits in front of the legacy system and owns routing. New, extracted services take over one path at a time; everything not yet migrated falls through to the monolith, untouched. Capabilities peel off into new services release by release, while the shrinking legacy monolith keeps serving whatever hasn’t moved yet — until there’s nothing left to retire. Users never see the seam.
Each migrated route is independently tested, shipped, and reversible. If something regresses, you reroute that one path back to the legacy system — no all-or-nothing rollback, no weekend war room. The business keeps running the entire time, and the technical-debt tax goes down every quarter instead of all at once at the end.
References
- Stripe & Harris Poll — The Developer Coefficient (2018)
- McKinsey — Tech debt: Reclaiming tech equity (2020)
- US GAO — Modernizing critical decades-old legacy systems (GAO-25-107795, 2025)
- Martin Fowler — Strangler Fig Application
- Thoughtworks — Embracing the Strangler Fig pattern for legacy modernization
Let's build it together
Tell us about your project and we'll map out a technical strategy — no commitment.
Get a quote