The most expensive sentence in enterprise software is "we should rewrite this." The second most expensive is "we should leave it alone." Both get said in meetings where nobody has actually priced the alternatives.
We spend most of our time on remediation and modernization work, which means we see the same decision made well and made badly across a lot of organizations. The pattern behind the good decisions is consistent enough to write down.
Four outcomes, not two
Most teams frame this as rewrite versus keep. There are four distinct outcomes, and the middle two are where most legacy applications should land:
Leave it running. The application is stable, changes rarely, and its runtime is supported. Spending money here is vanity. Document it, monitor it, move on.
Remediate. The application works but carries specific, nameable risk: an end-of-life runtime, unpatched dependencies, credentials in source, no backups that have ever been tested. Remediation fixes the risk without changing what the application does. It is the highest-return work in legacy software because the cost is bounded and the downside it prevents is not.
Modernize. The application matters to the business and needs to keep changing, but the platform is fighting you. Modernization moves it to a supported runtime, current infrastructure, and a sane deployment path while preserving behavior. Most of what gets pitched as a rewrite should be this instead.
Rewrite. The behavior itself is wrong for the business, or the codebase has degraded past the point where preserving it preserves anything of value. Rewrites are sometimes right. They are right far less often than they are proposed.
The five questions that sort applications into those buckets
1. Who screams if it goes down, and how fast? If the answer is "nobody for a week," you are looking at leave-it-running or retirement, no matter how old the code is. If the answer is "the CFO, within the hour," the application has earned real investment. Business criticality, not code quality, sets the budget.
2. How often does it need to change? Change frequency is the strongest signal separating remediation from modernization. A stable application on an old platform is a remediation candidate: secure it and stop. An application with a real feature backlog on an old platform is a modernization candidate, because every future change is paying the old-platform tax.
3. What is the actual risk exposure? Name it specifically. "It's old" is not a risk. "It runs on a ColdFusion version that stopped receiving security patches, faces the public internet, and touches payment data" is a risk, and it prices the remediation work for you. If you cannot name the exposure, you have an inventory problem before you have a modernization problem.
4. Does anyone still understand it? Institutional knowledge decays faster than code. If the last person who understood the batch jobs left two years ago, the cost of every option goes up, but it raises the cost of a rewrite the most, because a rewrite requires understanding what the application does at a level nobody currently has. This is one place AI-assisted analysis has changed the math: recovering a behavioral understanding of an undocumented system is dramatically cheaper than it was even two years ago.
5. What is it connected to? Integration surface is the hidden multiplier. An application with three quiet consumers is a contained project. An application that forty spreadsheets, two vendors, and an SFTP job depend on will punish any plan that treats it as standalone. Map the connections before choosing the bucket, not after.
The failure mode to avoid
The common thread in bad outcomes is skipping the sorting step and jumping to the answer that flatters someone. Rewrites flatter engineers. Leave-it-alone flatters budget owners. Remediation and modernization flatter nobody, which is exactly why they are underused and why they are usually right.
The discipline is to run the five questions before anyone proposes a solution, write down the answers, and let the application land in the bucket the answers point to. When the honest answer is "we don't know what this application does or touches," that is not a blocker. It is the first work package.
If you have an application you suspect belongs in one of the middle buckets, our ColdFusion migration and legacy modernization pages describe how we approach the work, and an AI readiness assessment is often the fastest way to find out what you actually have.