The average custom software project in 2026 costs $132,480 and runs 13 months, according to Clutch data, and a full rebuild of a legacy system routinely lands at two to four times that because the old system's undocumented behavior has to be rediscovered before it can be replaced (Launch Day Advisors). Most companies that ask us for a rebuild do not need one. They need the 20% of the system that is actively hurting them replaced, and the rest left alone until it earns replacement.
We modernize legacy systems for clients, and the recommendation we make most often is the one that bills the least. This post compares the four modernization approaches on cost, timeline, and risk, lays out the signals that point to each, and explains why the strangler fig pattern is the default answer for anything that still processes revenue. It does not cover mainframe migrations or ERP replatforming; those are specialist programs with their own economics. It covers the far more common case: a 5 to 15 year old web application, internal tool, or database-centered system that the business depends on and nobody wants to touch.
What is legacy system modernization?
Legacy system modernization is the process of updating or replacing software that still does its job but has become expensive, risky, or slow to change, so that it can support current business needs without a full rewrite where one is not justified. In practice it means choosing between four approaches: wrapping the existing system in an API, refactoring it in place, replacing it piece by piece (the strangler fig pattern), or rebuilding it outright. The right choice depends on where the pain actually is, which is rarely where the initial request says it is.
How do you know a system is legacy, as opposed to just old?
Age is not the criterion. Plenty of ten-year-old systems are fine. A system is legacy when it fails one or more of these tests, and the number of failures tells you how urgent the work is.
- Change cost. A small feature takes weeks because nobody is confident what else will break. Ask the team how long the last three "simple" changes took.
- Key-person risk. One or two people understand it, and one of them is thinking about leaving.
- Unsupported foundations. The framework, language runtime, or database version no longer receives security patches. This one converts from "risk" to "incident" on its own schedule.
- Integration friction. Every new tool needs a custom bridge because the system has no API, only a database other systems reach into directly.
- Operating cost. Hosting, licences, or manual workarounds cost more each year than a replacement would over three.
- Compliance blockers. An audit, a customer security questionnaire, or a regulation (SOC 2, HIPAA, PCI DSS) cannot be satisfied without changes the system cannot absorb.
The four modernization approaches compared
| Approach | What it is | Typical cost vs rebuild | Time to first value | Risk profile |
|---|---|---|---|---|
| Wrap (API facade) | Leave the system alone; put a modern API and integration layer in front of it | 10% to 20% | 4 to 10 weeks | Low. Old system untouched; risk is in the facade's assumptions |
| Refactor in place | Upgrade runtime, add tests, restructure the worst modules, keep the architecture | 20% to 40% | Continuous, from week 2 | Low to medium. Every change is small and reversible |
| Strangler fig | Route traffic through a facade; replace one capability at a time with a new service; retire the old one when nothing calls it | 60% to 110% over 12 to 24 months, spread out | 8 to 14 weeks for the first replaced capability | Medium, bounded. Each slice can be rolled back independently |
| Rebuild | Write a new system, migrate data, cut over | 100%, often 150% to 250% once rediscovery is counted | 9 to 18 months, all at the end | High. Big-bang cutover, parallel running, and the second-system effect |
The cost column is the one people argue with, so the reasoning: a rebuild has to reproduce every behavior the business relies on, including the ones nobody documented and the ones that are actually bugs users have learned to depend on. Discovering those is a research project that happens during the build, which is why rebuilds overrun. A strangler fig discovers them one capability at a time, with the old system still running as the reference implementation. Martin Fowler named the pattern after a fig that grows around a host tree until the host is gone (Martin Fowler), and the image is exact: the old system keeps the lights on while the new one grows.
Which approach fits which situation?
The decision comes down to two questions: where is the pain, and can the system keep running while you fix it? This matrix is what we use in the first scoping conversation.
| Signal | Wrap | Refactor | Strangler fig | Rebuild |
|---|---|---|---|---|
| Core logic is sound; problem is integration | Best fit | Sometimes | Overkill | No |
| Runtime or framework is out of support | Buys time only | Best fit if the codebase is testable | Good if modules are separable | If refactoring is blocked |
| Two or three modules cause most change pain | No | Sometimes | Best fit | No |
| System processes revenue every day | Fine | Fine | Best fit; no big-bang cutover | Highest risk option |
| Data model is fundamentally wrong for the business | Hides it, briefly | Cannot fix it | Possible with a new data service per slice | Best fit |
| Small system, few users, low change volume | Fine | Fine | Too much ceremony | Best fit if cheap |
| Nobody understands the code and there are no tests | Fine short term | Dangerous | Best fit; old system is the spec | Only after characterization tests exist |
Two patterns from that matrix. Rebuild wins only when the data model is wrong or the system is small enough to be cheap. Strangler fig wins in most other cases where a system matters, because it converts one large irreversible risk into a series of small reversible ones. That is also the argument we make in custom software vs off-the-shelf: the question is never "new or old," it is "which parts justify their cost."
How the strangler fig pattern works in practice
- Put a facade in front of the system. A reverse proxy, API gateway, or thin service that every consumer now calls. Nothing changes behind it yet. This step alone often takes 2 to 4 weeks and is the same work as the "wrap" approach.
- Write characterization tests for the first capability. Record what the old system actually does for a set of real inputs, including the odd cases. These tests are the specification; the code is not.
- Build the replacement for that one capability. A single bounded service, on a modern stack, with its own data store if the domain justifies it. Typical size: 6 to 10 weeks of work for a meaningful business capability.
- Route a slice of traffic to it and compare. Shadow mode first (both systems run, only the old one answers), then a percentage, then all of it. Any mismatch is a bug in the new system or an undocumented behavior in the old one, and both are worth knowing.
- Retire the old capability. Delete the code path. Resist the urge to keep it "just in case"; two live implementations are worse than one.
- Repeat, in pain order. The next slice is whichever capability is costing the most in change time or incidents. Stop when the remaining legacy is cheap to keep.
The last point is the one that saves money. A strangler fig program does not have to finish. If 40% of the old system is stable, cheap, and rarely changes, leaving it behind the facade indefinitely is the correct engineering decision, not a failure.
What modernization costs, and where the money actually goes
Using our published engagement tiers as anchors: the facade and first replaced capability typically land in the $25k to $60k range over 8 to 14 weeks, comparable to a lean MVP; a program that replaces the three or four capabilities causing most of the pain runs $80k to $180k over 6 to 12 months. A full rebuild of a mid-sized business system starts around $150k and, in our experience, the quotes below that number omit data migration, parallel running, or the rediscovery work. The hidden cost of cheap software post explains why the low quote is the expensive one.
Two line items surprise clients. Data migration is 15% to 30% of a rebuild and near zero for a strangler fig, because each slice migrates only its own data. And maintenance continues throughout: published 2026 benchmarks put ongoing maintenance at 15% to 25% of build cost per year, and the old system still needs patching while the new one grows. Budget both.
Three mistakes that turn modernization into a rescue
- Rebuilding from the code instead of the behavior. Teams read the old code, decide what it "should" do, and build that. The business depended on what it actually did. Characterization tests first, always. This is the same discipline as writing the spec before the code, which we cover in spec-driven development.
- Letting an AI coding tool rewrite modules wholesale. AI tools are excellent at translating a well-understood module to a new stack and dangerous at translating a poorly understood one, because they produce confident code for behavior nobody verified. The 2026 Stack Overflow survey found 84% of developers use AI tools and only 3% highly trust the output (Stack Overflow survey summary). Use them behind characterization tests, never instead of them. If a previous attempt already went this way, the recovery sequence is in our AI-generated app rescue playbook.
- Modernizing the stack and keeping the integration mess. If six other systems read from the legacy database directly, a new database with the same six direct readers is the same problem in a newer font. The facade has to become the only door, which is the whole point of our API integration guide.
Frequently asked questions
What is the strangler fig pattern?
A modernization approach in which a facade is placed in front of a legacy system and its capabilities are replaced one at a time with new services, routing traffic to each replacement as it proves itself, until the old system is retired or reduced to the parts that are cheap to keep. It avoids a big-bang cutover and lets the old system serve as the specification for the new one.
How much does legacy system modernization cost?
Wrapping a system in an API typically costs 10% to 20% of a rebuild, refactoring 20% to 40%, and a strangler fig program 60% to 110% spread over 12 to 24 months. A full rebuild of a mid-sized business system starts around $150k and frequently reaches 150% to 250% of its initial estimate once undocumented behavior, data migration, and parallel running are counted.
When is a full rebuild the right choice?
When the data model is fundamentally wrong for the business, or when the system is small enough that a rebuild is cheaper than the ceremony of incremental replacement. In both cases, write characterization tests against the old system first so the rebuild targets actual behavior rather than assumed behavior.
How long does modernization take?
A facade and the first replaced capability take 8 to 14 weeks. A program addressing the three or four most painful capabilities takes 6 to 12 months. A rebuild takes 9 to 18 months with value delivered only at cutover, which is the main reason we recommend against it for systems that process revenue daily.
Can we keep using the legacy system during modernization?
Yes, and with the strangler fig approach you should. The old system keeps running behind the facade, answering requests for every capability that has not yet been replaced, and serves as the reference implementation for comparison testing of each new slice.
Key takeaways
- Most rebuild requests are strangler fig projects in disguise. Replace the 20% causing pain; leave the rest until it earns replacement.
- Four approaches, in rising cost and risk: wrap, refactor, strangler fig, rebuild. Rebuild wins only for a wrong data model or a small, cheap system.
- Rebuilds overrun because undocumented behavior is rediscovered mid-build. A strangler fig discovers it one slice at a time with the old system as reference.
- Characterization tests are the specification. Never let anyone, human or AI, rewrite a module whose behavior has not been recorded.
- The facade must become the only door. Modernizing the stack while six systems still read the database directly changes nothing.
- A strangler fig program does not have to finish. Stopping when the remaining legacy is cheap to keep is the correct outcome.
Find out which 20% is hurting you
If you have a system everyone is afraid to touch, describe it to us: stack, age, what the last three changes cost, and what breaks. We will come back with a one-page recommendation naming which of the four approaches fits, what the first slice should be, and a cost range for it. If the honest answer is "wrap it and move on," that is what we will say; a facade is a better outcome for you than a rebuild is for our custom software development pipeline.
Sources
- Martin Fowler: Strangler Fig Application
- Launch Day Advisors: Custom software development cost (Clutch 2026 data)
- Andersen: Custom software development costs in 2026
- Stack Overflow Developer Survey 2026 summary: AI usage and trust
- Cloud Security Alliance: AI-generated code vulnerability surge (April 2026)