There is no formula, and that is the answer
Most sources on this topic suggest a threshold: replace your system when annual maintenance is more than 30% of the original build cost, when repairs take four times longer than they used to, or when the cost crossover happens within two years.
I tried to find the sources for these numbers. None are cited. One modernization consultancy lists seven different numeric triggers, but not a single footnote.
This isn't by accident. The sources you'd expect to set a threshold simply don't provide one.
- Lehman's first law of software evolution says a system keeps changing "until it is judged more cost effective to replace the system with a recreated version". It names a judgment and then stops.
- The most formal method available, the Software Engineering Institute's Options Analysis for Reengineering, tells the team to develop its own criteria. The threshold is something you supply, not something the method returns.
- ISO/IEC/IEEE 14764 has an entire Replacement clause and sets no numeric test in it.
- Gartner's TIME model plots technical fit against functional fit and has no financial axis anywhere in it.
- A peer reviewed research agenda published in 2024 lists "decide among replace, maintain, evolve, re-engineer, or migrate" as an open problem the field still needs solutions for.
If the field's own research says this question is still unsolved, there's no agreed threshold. Anyone claiming otherwise is making it up. Here's what you can actually check.
The statistic you are about to be quoted
You'll probably hear that organizations spend 60 to 80 percent of their IT budgets on maintenance. I tried to track down the source. It leads from modernization blogs, to a magazine article that now returns a 404, to a consultancy page with no content. There's no real study behind it.
The number that is real, and checkable, is narrower. In July 2025 the US Government Accountability Office reported that about $83 billion, roughly 79 percent of planned federal IT spending across the major agencies, was for operations and maintenance rather than development or modernization. It also found that the eleven federal systems most in need of replacement are between 23 and 60 years old and cost around $754 million a year just to run.
Keep the context in mind: this data is about the US federal government, which has more legacy systems and stricter procurement rules than most. Using it as a general fact about all organizations is a common mistake, and careful readers will notice.
What actually decides it is dates, not economics
Here, the evidence is clear and easy to verify. Platform vendors publish the exact dates when they stop providing security updates, and those dates don't depend on your budget.
A few, from the vendors' own pages: PHP 7.4 stopped receiving security support on 28 November 2022, PHP 8.0 on 26 November 2023 and PHP 8.1 on 31 December 2025. Extended support for Windows Server 2012 R2 ended on 11 October 2023, with paid Extended Security Updates running only to 14 October 2026.
| Product and version | Support that ends | Date |
|---|---|---|
| PHP 7.4 | Security support | 28 November 2022 |
| PHP 8.0 | Security support | 26 November 2023 |
| PHP 8.1 | Security support | 31 December 2025 |
| Windows Server 2012 R2 | Extended support | 11 October 2023 |
| Windows Server 2012 R2 | Paid Extended Security Updates | 14 October 2026 |
Then the part most people miss. Since 31 March 2025, PCI DSS Requirement 12.3.4 has required organizations in scope to review at least annually whether their hardware and software are still vendor-supported, and to document a remediation plan for anything that is not. If you take card payments, running end-of-life software stopped being a judgment call and became a documented finding.
So the real way to answer "is it time" isn't by using a ratio. List every platform your system relies on, check their end-of-life dates, and see which ones are past. This takes an afternoon and gives you something concrete to show your board.
The risk is shaped differently than you have been told
You'll also hear that software projects often go way over budget. But the best data tells a more useful, if less catchy, story.
| Measure | Cost overrun |
|---|---|
| Mean | 80% |
| Median | 0% |
Look closely at the data, because it tells both sides. It's not true that software projects always run over budget. Most finish on budget. But don't get too comfortable, because the real risk is in the rare but severe overruns. An earlier study found about one in six projects went 200 percent over cost.
In practice, don't plan your replacement project based on the average result, because the average isn't what causes problems. Instead, plan so that if things go wrong, you can stop at any stage and still have something useful delivered.
Four questions that beat any threshold
- Which parts of your system are already past their end-of-life date, and which ones are next? You can check this in an afternoon, and once it's written down, it's clear.
- Can you still hire people who know this system? The issue isn't just whether the technology is old, but whether you can replace the person who understands it. A system that only one person knows is a bigger risk than an old system several people can support.
- How long does it take to make a change now? Don't rely on opinions about technical debt. Instead, count the days between requesting a change and having it live, based on your last five changes. If that number is increasing, it's a warning sign.
- What would actually break if the system stopped working today? Not every system is critical. Sometimes, systems are replaced that no one really needed.
If you answer these four questions, you usually won't need a ratio. The answer will be clear. If it's still not clear, that's a sign your system is probably fine and the real issue lies elsewhere.
When to keep it
There are three situations where keeping your system makes sense, and they're more common than the modernization industry admits.
If your system works, is supported, and doesn't need constant changes, that's a good thing. Age alone isn't a problem. A system that hasn't needed updates in six years is a success, not a liability. Often, "legacy" just means the software is complete.
If you can't explain what the replacement system does differently, it may not be worth it. Rebuilding the same features in a new framework just adds migration risk and brings back bugs you've already fixed.
If no one is responsible for the outcome, replacement projects often fail, not because of technical issues, but because key decisions aren't made. Make sure someone can make final calls before you spend money.
And for fairness, since the horror stories get repeated more than the rest: the audited record contains successes too. The GAO found the IRS modernization portfolio in 2024 mostly on schedule and about $512 million under plan, before it was paused for reasons that had nothing to do with overruns.
How I would approach it
A Diagnostic Week costs $2,500, fixed. For this question, the results are straightforward: you get an end-of-life list, a measure of change costs, an honest assessment of hiring risk, and a fixed quote for whatever the answer is. You keep all of this, no matter what you decide next.
Builds typically cost between $15,000 and $50,000, based on the Diagnostic Week. If the real issue is a process or a person, not your system, that's what the report will say. I'd rather tell you that than sell you an unnecessary replacement.