Legacy System: Definition & Examples
A legacy system is business-critical software that the organization still depends on but can no longer change quickly or safely. What makes it legacy is not age — it is the gap between what the business now needs the system to do and what the system can be changed to do. A well-maintained twenty-year-old system may not be legacy; a brittle five-year-old one can be.
Every large organization runs on at least one system it is afraid to touch. The code still works, payroll runs, claims process, orders ship, but the system has become a constraint on the business rather than an enabler of it. That is a legacy system.
What actually makes a system “legacy”
The instinct is to define legacy by age, but age is the wrong axis. The real definition is a gap: the distance between what the business now needs the system to do and what the system can safely be changed to do.
That gap shows up as symptoms: every feature takes weeks, maintenance eats a growing share of the budget, the people who understand the system are retiring, and security or compliance findings pile up against unpatched runtimes. A system becomes legacy when those pressures arrive faster than it can absorb them. A well-maintained system can be old and not legacy. A neglected one can be legacy while still young. A five-year-old application built quickly, with no tests and one engineer who has since left, can be harder and riskier to change than a forty-year-old mainframe system that has been carefully maintained the whole way.
Examples
The label spans technologies: COBOL on the mainframe, RPG on AS/400 (IBM i), Oracle Forms and PL/SQL, .NET Framework and Java EE monoliths, Visual Basic 6 line-of-business tools. What unites them is not a language, it is that each is critical, hard to change, and increasingly hard to staff. If you are unsure whether a runtime under one of these systems is still supported, the software EOL checker is a fast first read.
The same label applies well beyond those obvious cases. A five-year-old Node.js service with no tests and a single author who left the company is a legacy system by the definition that matters, even though nothing about its age or language looks “legacy” on paper.
What to do about it
Recognizing a legacy system is the easy part. The harder question is what to do about it, and the honest answer depends on what the system does, not how old it is.
| Path | When it fits |
|---|---|
| Leave it alone | Stable, no roadmap or compliance pressure, cheaper to run than to change |
| Modernize incrementally | Still business-critical and needed, but change has become slow or risky |
| Replace with a package | The capability is now a commodity a vendor solves well |
| Retire | The capability is no longer needed, or has been absorbed elsewhere |
Most large estates end up doing all four across different systems at once. The mistake is applying one answer, usually “modernize everything” or “replace everything”, uniformly across a portfolio that actually needs a different call per system.
Why it matters
Legacy systems are expensive in ways that do not show up as a line item. Deloitte’s CIO surveys put roughly 55-57% of enterprise IT budgets on running existing systems rather than building new capability (Deloitte, 2016-2020), and the share tends to grow as systems age. The deeper cost is opportunity: the roadmap the business cannot pursue because the core cannot move. The legacy cost calculator turns that into a number for a specific system.
How it relates to modernization
A legacy system is the starting condition of legacy modernization, the thing being modernized. But “legacy” is not a verdict that demands a rewrite. The first question is never “how do we modernize this?” It is “what does the business need that this system is blocking?” If the answer is nothing, the honest move may be to leave it running, or to retire it. Legacy describes a situation, not a sentence. For the full checklist of symptoms that tell you a system has crossed the line, see Signs Your System Has Become Legacy.
Frequently asked questions
- What are examples of legacy systems?
- Common examples include mainframe applications written in COBOL, AS/400 (IBM i) RPG systems, Oracle Forms and PL/SQL applications, .NET Framework and Java EE monoliths, and Visual Basic 6 line-of-business tools. What they share is not a language — it is being critical, hard to change, and increasingly hard to staff.
- Is a legacy system the same as an old system?
- No. Age is the wrong axis. A legacy system is one where change has become slow, risky, or dependent on knowledge that has left the building. Some old systems are well-maintained and easy to change; some recent ones are already legacy.
- When should a legacy system be left alone?
- When it is stable, under no roadmap or compliance pressure, and cheaper to keep running than to change. Modernization is a means, not a goal. If nothing the business needs is blocked, leaving the system alone, or retiring it, can be the right call.
- How do you know if a system has become legacy?
- Watch the pattern of pain, not any single incident. Every feature takes weeks longer than it should. Maintenance eats a growing share of the budget. The people who understand the system are retiring. Security or compliance findings pile up against a runtime past its support window. One of these can happen to a healthy system; several of them together, and getting worse, is the signal.
- Should you replace a legacy system or modernize it incrementally?
- It depends on what the system does. If the capability is now a commodity a vendor solves well, a generic HR or expense workflow, buying a package often beats rebuilding one. If the system encodes business rules and behavior that are genuinely specific to the company, especially rules nobody has fully documented, incremental modernization preserves that knowledge while a like-for-like replacement risks losing it. A full replacement is rarely the first option to reach for.