Signs Your System Has Become Legacy

Part 1 defined a legacy system by a single idea: the gap between what the business needs and what the system can safely be changed to do. That definition is correct, but it is abstract. This part makes it operational. The gap is not something you feel — it is something you can read off your own delivery metrics, your budget, your org chart, and your audit findings. The signs below are how the gap surfaces in practice, and how to tell a real warning from ordinary aging.

Age is not a sign

Start by discarding the most common one. A system is not legacy because it is old, written in an unfashionable language, or runs on a mainframe. COBOL still settles a large share of the world’s financial transactions, and much of it does so reliably, every day. The systems that built your business deserve a future as serious as their past — and many of them are not in trouble at all.

Legacy is a functional condition, not a chronological one. The question is never “how old is it?” but “what is it now costing us to change, and what is the business unable to do as a result?” A clean, documented, well-tested twenty-year-old system may be in excellent health. A brittle, undocumented three-year-old one, hacked together against a launch date, may already be legacy. Read the symptoms, not the birth certificate.

Sign 1: change is slow and getting slower

The first and most expensive sign is lead time for change — the elapsed time from “the business wants this” to “it is live and safe.” In a healthy system, a small feature is a small effort. In a legacy system, every change drags in dependencies nobody can fully see, requires regression testing nobody fully trusts, and waits on the one person who understands the affected area.

Watch the trend, not the absolute number. If a change that took days last year takes weeks now, the system is hardening against you. The mechanism is usually accumulated coupling: over years, modules grow tendrils into each other until no part can move without disturbing the rest. The visible result is a roadmap that keeps slipping for reasons engineering struggles to explain to the business — because the reason is structural, not a matter of effort.

Sign 2: maintenance is eating the budget

The second sign is financial. Track the split between keeping the lights on and building new capability. In a system that is aging badly, the maintenance share climbs every year — more spend, less innovation — until new work is squeezed into the margins.

This is not a niche problem. Deloitte’s CIO surveys have found that roughly 55–57% of enterprise IT spend goes to running existing systems rather than building new ones. That is the industry’s gravitational baseline, and a legacy system pulls your own ratio toward it. When most of the engineering budget defends the past instead of funding the future, the system has quietly become a cost center that taxes every other initiative.

The tell is not a single large bill but a steady drift: each release a little more careful, each environment a little more fragile, each upgrade a little more expensive, with no single decision you can point to as the cause.

Sign 3: the knowledge is walking out the door

The third sign is human, and it is the one most often missed until it is acute. Critical systems accumulate undocumented behavior — the rule that handles the one customer who is invoiced differently, the workaround for the integration that breaks at month-end, the reason a field is validated the way it is. Over years, that knowledge lives in a shrinking set of heads rather than in the code or the docs.

Count the bus factor per subsystem: how many people could safely make a non-trivial change here? When the answer for an important area is “one,” and that person is within sight of retirement or already half out the door, you are running on borrowed time. The pipeline of new engineers fluent in the old stack is dry; the people who remember why it works are leaving. When they go, the knowledge does not transfer — it evaporates, and the next change becomes archaeology.

Sign 4: security and compliance risk is accumulating

The fourth sign is risk you cannot patch away. Legacy systems tend to sit on runtimes, frameworks, and operating systems that have passed end-of-support. Vendors stop shipping security fixes; auditors start writing findings; the gap between “what a current system would do” and “what this one can do” becomes a line item in every risk review.

The danger is that this sign accumulates silently and then arrives all at once — a regulation changes, a dependency is declared vulnerable, an auditor declines to sign off. Unlike slow change or rising cost, which degrade gradually, compliance risk often presents as a hard deadline imposed from outside. If your system depends on components that are no longer supported, you do not control the timeline anymore; someone else does.

Sign 5: the people who use it route around it

The last sign points outward, to the users. A system that has fallen behind its job spawns shadow processes: the spreadsheet that holds the data the system can’t, the second tool the team actually relies on, the manual reconciliation step that exists because the system can no longer be trusted to do it. Poor usability and missing capability push users to work around the system instead of through it.

When that happens, the system stops being a single source of truth and becomes one input among several — which is dangerous, because the business is now running on processes nobody designed and nobody owns. The data drifts, the workarounds calcify, and the real system of record moves into places IT cannot see or protect.

Reading the signs together

No single sign is decisive. Any one of them can have a benign explanation — a slow quarter, one retirement, a single audit note. The condition is the pattern: several signs trending the wrong way at once, reinforcing each other. Use this table to score your own system honestly.

Sign	Healthy	Becoming legacy	How to measure it
Speed of change	Small change, small effort	Every change is weeks and risk	Lead time for change, trended over quarters
Cost balance	Most spend funds new work	Maintenance crowds out everything	Maintenance vs. new-build share of budget
Knowledge	Many can safely change it	One person holds each area	Bus factor per subsystem
Risk	Supported, patched, audit-clean	Findings accumulate, no fixes	Open findings against unsupported runtimes
Usability	Users work through the system	Users build shadow processes	Count of off-system workarounds

If most rows sit in the middle column and the arrows point right, the system has crossed from old to legacy. The cost of that condition compounds: every quarter you wait, change gets a little slower, the knowledge thins a little more, and the eventual effort grows.

A prompt, not a verdict

Recognizing the signs tells you a system is becoming a liability. It does not, by itself, tell you to modernize — and acting on the symptoms alone is how programs start for the wrong reasons. A system can show every sign and still be the wrong thing to invest in, because the right move might be to retire it, to replace it with something bought off the shelf, or to leave it largely alone and modernize only the one slice that is actually blocking the business.

The signs are a prompt to investigate, not a mandate to rebuild. The disciplined response is to measure the gap, understand which parts of the system are actually holding the business back, and only then choose a response — proportionate to the problem, not to the anxiety the symptoms create.

Where this leads

You now have a way to tell whether a system has genuinely become legacy and where the pain is concentrated. The next question is what to do about it — and the answer is not a single option. Modernization is a spectrum of distinct moves, each suited to a different kind of problem. Part 3, The 7 Rs of Modernization Explained, lays out all seven so you can match the right response to each sign you just diagnosed.