An old system can have a reasonable support budget and run reliably for years. That is why the question “what does our legacy cost?” often gets an answer that is too simple: infrastructure, licenses, and the team.
The bigger cost usually appears every time the business wants to change something.
The cost of change grows quietly
A small feature requires touching several old modules. A simple integration becomes a project. A release needs manual checks and a carefully managed window.
The business is not paying for age itself. It is paying because movement around the system becomes expensive.
Legacy slows business decisions
If technology makes it hard to test a hypothesis, launch a product, or connect a partner quickly, the limitation is already a business issue.
The company starts choosing not the best option, but the one the current system can tolerate.
Knowledge becomes concentrated
The more historical exceptions and undocumented behavior a system contains, the more the organization depends on people who “just know how it works.”
Those specialists are not the problem. The problem is that critical knowledge lives in a few heads.
Hiring becomes part of the bill
Older stacks may be harder to hire for, and new engineers need more time to understand the system before they can change it safely.
Even without higher salaries, onboarding time and dependence on narrow expertise are real costs.
Not every old system should be rewritten
Age alone proves nothing. A system can be old, inexpensive, understandable, and stable.
Rewriting for the sake of a modern stack can create more risk than value. The useful measure is not age, but the future cost of change.
A better business question
Instead of asking “how outdated is this system?”, ask how much time and risk it adds to a typical business change.
Legacy becomes expensive when the company pays for yesterday's decisions every time it tries to move forward.