The right modernization strategy depends on two variables: how much business value the system still delivers, and how technically viable its platform remains. A system with high business value on a dying platform justifies a rewrite. High value on a viable platform calls for refactoring. Low value on a viable platform should be left alone. Low value on a dying platform should be replaced with something off the shelf, or retired. Most failed modernization programmes are the result of choosing a full rewrite when incremental refactoring would have worked.
Key Takeaways
- Modernization has six options, not two. Retain, rehost, replatform, refactor, rebuild and replace differ enormously in cost and risk.
- Rehost: 10–20% of original build cost. Refactor: 25–50%. Full rewrite: 80–150%.
- The strangler fig pattern — replacing capabilities incrementally behind a routing facade — is the lowest-risk path for large systems and should be the default for anything business-critical.
- A rewrite’s real risk is not the code. It is the undocumented behavior accumulated over a decade that exists nowhere except in the running system.
- Modernization pays back in 18–36 months in most viable cases. If you cannot construct that case, the honest answer may be to do nothing.
- Never rewrite and add features simultaneously. A rewrite with a moving target is the single most reliable way to fail.
The Six Options
“Modernization” gets used to mean a full rewrite. It should not. There are six distinct strategies, and cost varies by more than an order of magnitude between them.
| Strategy | What it means | Cost (% of original build) | Risk | Timeline |
|---|---|---|---|---|
| Retain | Leave it; invest elsewhere | 0% | None | — |
| Rehost | Lift and shift to cloud, unchanged | 10–20% | Low | 1–4 months |
| Replatform | Move and modernize the runtime — managed DB, containers | 15–30% | Low–medium | 2–6 months |
| Refactor | Restructure the code incrementally, same system | 25–50% | Medium | 4–12 months |
| Rebuild | Rewrite from scratch, same purpose | 80–150% | High | 9–30 months |
| Replace | Buy a commercial product instead | Licence + migration | Medium | 3–12 months |
Two observations from that table. Rehosting is remarkably cheap and often solves the pressing problem — if the pain is unsupported hardware, spiralling data centre costs or an inability to scale, moving the system unchanged to cloud infrastructure may resolve it for a fifth of a rewrite’s cost. And “replace” is systematically under-considered. Engineering organisations are biased toward building. If a mature commercial product covers 85% of what your custom system does, buying it and adapting your process to the remaining 15% is frequently the correct commercial answer.
The Decision Framework
Score your system on two axes.
Axis 1 — Business value. Does this system differentiate you competitively? Would customers notice if it disappeared? Does it encode genuinely proprietary domain logic? Is it central to revenue?
Axis 2 — Technical viability. Is the platform still supported and receiving security patches? Can you hire people who know it? Can you deploy safely? Is there meaningful test coverage? Does anyone still working here understand it?
| Low technical viability | High technical viability | |
|---|---|---|
| High business value | Rebuild or aggressive refactor. This is the only quadrant where a rewrite is clearly justified. | Refactor incrementally. Invest in tests, modularity, observability. Do not rewrite. |
| Low business value | Replace with a commercial product, or retire. Do not rewrite a commodity system. | Retain. It works. Spend the budget somewhere it creates value. |
The quadrant that produces the most wasted money is bottom-left treated as top-left: rewriting a system that does something entirely standard — payroll, ticketing, inventory — because it is old, when a commercial product would do it better for a tenth of the cost.
A Scoring Model
If the quadrants feel too coarse, score each dimension 1–5 and total it.
Rewrite pressure — score 1 (no) to 5 (severe):
| Signal | Score |
|---|---|
| Platform is end-of-life with no upgrade path | 1–5 |
| Unable to hire or retain people with the required skills | 1–5 |
| Security vulnerabilities that cannot be patched | 1–5 |
| Business model changed such that the data model is now wrong | 1–5 |
| No test coverage and changes routinely break unrelated things | 1–5 |
| Nobody currently employed understands core components | 1–5 |
| Cannot integrate with systems the business now requires | 1–5 |
- 7–14 — Retain or rehost. The problem is not the software.
- 15–21 — Replatform or refactor incrementally.
- 22–28 — Serious refactoring, probably strangler fig.
- 29–35 — Rebuild is defensible. Read the next section before you commit.
Why Rewrites Fail
The failure mode is consistent enough to be predictable.
The behavior is not in the specification; it is in the code. A system that ran for twelve years accumulated hundreds of small behaviors — a discount rule for one customer segment, a rounding convention finance depends on, an export format a partner’s system requires. None of it is written down. The rewrite discovers these one at a time, in production, after cutover, when the finance team notices the numbers are wrong.
The target moves. The business does not stop for eighteen months. Either the new system launches missing everything added to the old one during the build, or the team maintains both, which costs more than either alone.
Cutover risk is concentrated. A big-bang replacement puts the entire risk of the project into a single weekend. When something goes wrong at 3am, the rollback plan is theoretical.
Value arrives only at the end. Twelve months of spending with nothing shipped is politically fragile. Rewrites are frequently cancelled at 70% completion, having produced nothing.
If you rewrite anyway, mitigate deliberately: freeze features on the old system, run both systems in parallel with automated output reconciliation, migrate one capability at a time, and use characterization tests — capture real production inputs and outputs from the legacy system and assert the new one matches. That last technique converts undocumented behavior from a discovery risk into a test suite.
The Strangler Fig Pattern
Named after the fig that grows around a host tree until the tree is gone, this is the pattern that makes large modernizations survivable.
- Put a facade in front of the legacy system — an API gateway or reverse proxy. All traffic routes through it. Nothing changes yet.
- Pick one capability, ideally at the edge of the domain with few dependencies.
- Build that capability new, and route only its traffic to the new service.
- Verify in production by running both and comparing outputs before switching fully.
- Repeat, capability by capability.
- Retire the legacy system when it serves no traffic.
The advantages are decisive: value ships in weeks rather than years, each step is individually reversible, the team learns the domain incrementally, and the project can be paused at any point without losing what has been delivered.
The costs are real too: you maintain two systems during transition, the facade and any data synchronisation are genuine engineering work, and total elapsed time is longer than a successful big-bang rewrite would have been. That last point is worth stating honestly — strangler fig trades speed for survivability. For a business-critical system, that is a trade worth making. We used essentially this approach when layering modern capability over legacy hospitality systems, and the pattern generalises well beyond that vertical.
Building the Business Case
Modernization competes for budget against things with obvious revenue attached. It needs a number.
Annual cost of the status quo:
| Line item | How to quantify |
|---|---|
| Legacy licence and support | Direct invoice |
| Infrastructure / data centre | Direct invoice, including facilities |
| Maintenance engineering | Engineer-hours × loaded cost |
| Incident and downtime cost | Incidents × mean duration × cost per hour |
| Specialist premium | Extra cost of hiring scarce legacy skills |
| Compliance exposure | Cost of remediation, or realistic risk-adjusted penalty |
| Opportunity cost | Revenue from features you cannot ship |
That last row is usually the largest and is almost always omitted. If your competitors ship a capability in six weeks and it takes you nine months because of the legacy system, that difference has a revenue number attached.
Against: modernization cost, new run cost, transition period double-running, training and change management.
Most defensible cases pay back in 18–36 months. If you cannot construct that case honestly, the correct decision may well be to retain the system and spend the money elsewhere — which is a legitimate outcome of this analysis, not a failure of it. Our hidden tax of legacy tech piece works through this calculation with a concrete example.
How NSDBytes Approaches Modernization
Our app modernization engagements start with an assessment, not a proposal to rebuild. Typically two to four weeks, producing:
- A dependency and capability map of what the system actually does, derived from the code and from production traffic rather than from documentation nobody trusts.
- A risk register identifying the components where behavior is least understood — which is where the cost hides.
- A scored recommendation across the six strategies, with cost ranges.
- A phased plan with value delivered in the first 90 days.
We recommend “retain” more often than clients expect. A system that works, that people understand, and that is not blocking the business does not need our attention regardless of how old the framework is. Where a rewrite is genuinely warranted, we default to strangler fig, and we insist on characterization testing before any capability is cut over. Our application support and maintenance team frequently takes over systems afterward, which gives us an incentive to leave them maintainable.
Final Thoughts
Age is not a reason to rewrite. Cost, risk and the inability to change are. Score the system honestly on business value and technical viability, consider all six strategies rather than the two that come to mind, and prefer incremental paths for anything the business depends on.
If you have a legacy system and want an assessment rather than a sales pitch, get in touch.
Related Articles
Frequently Asked Questions
Written by the NSDBytes Team
We are passionate about software development, AI integration, and helping businesses achieve operational excellence through modern technology.
Need something like this built?
We’ve helped 200+ companies build and scale production-grade software.
