Most articles on this subject are written for engineers, by engineers, about things engineers can see. That is not useful to the person who usually notices first.
The person who notices first is often not technical. They notice that shipping got slow, that good people left, that nobody can answer a security questionnaire without a fire drill. They have the instinct and none of the vocabulary, so they say nothing, and the instinct turns out to have been right about eighteen months later.
These are twelve signs of legacy system failure that a CEO, CFO or COO can verify personally — no code, no engineering translation. Ten minutes and a few direct questions.
People signs
1. A new senior engineer takes more than six weeks to ship unsupervised. Ask your engineering manager how long the last senior hire took to deploy something to production on their own. Under two weeks is healthy. Over six weeks means the system cannot be understood from the outside, which means it cannot be maintained by anyone except the people already there.
2. There is a person the system cannot survive. Everyone knows their name. If they took a month off, something would break that nobody else could fix. This is usually framed as a compliment about that person. It is a description of an uninsured risk.
3. Engineering attrition is above your company average, and has been for two years. Your HR system already knows this. Engineers leave failing systems before they leave companies, and they rarely say so in the exit interview — “new opportunity” is easier than “I spent two years unable to do good work.”
4. Nobody volunteers to own it. When a team reorganizes, notice which system nobody asks for. Engineers avoid codebases where effort does not convert into progress. That avoidance is an expert assessment, delivered silently.
Process signs
5. Deploys are events. Ask: can we release on a Friday afternoon? If the answer involves a pause, a wince, or a policy, the system is telling you it is not safe to change. Healthy systems ship on Fridays and nobody thinks about it.
6. Estimates have stopped being useful. Not “estimates are sometimes wrong” — that is normal. The sign is that the same work takes wildly different amounts of time depending on what it touches, and nobody can predict which. That’s a symptom of hidden coupling, and it gets worse, not better.
7. “Too risky to touch” has been said out loud about a real feature. In the last twelve months, has anyone declined to change something because the blast radius was unknown? Write down which feature. That’s the part of your business that has stopped being under your control.
8. Shipping slowed down while headcount went up. The most expensive sign, and the one that shows up clearly in your own numbers. Compare features shipped per quarter over three years against engineering headcount over the same period. If the lines have diverged, you are buying more capacity and receiving less output — the difference is being consumed by the system itself.
Code signs (still verifiable without reading any)
9. There is no automated test suite worth the name. You don’t need to assess the tests. Ask one question: “if we changed something important, how would we know we hadn’t broken anything else?” If the answer is a person’s name or a manual checklist, there is no safety net, and every change is a gamble with a long settlement period.
10. A core dependency is past end-of-life. Ask whether anything critical runs on a version no longer receiving security patches, and whether upgrading is blocked by something else. This has a deadline attached that is not set by you — it’s set by whoever finds the vulnerability first.
11. Nobody can draw the system on a whiteboard. Ask three senior people to sketch the architecture separately. If the three drawings disagree in material ways, there is no shared model of how the thing works. Every change is then made against a private and partly wrong mental map.
Risk signs
12. A security or compliance questionnaire triggers a scramble. An enterprise prospect, an insurer or an auditor sends a standard questionnaire. Does answering it take a week of senior engineering time and produce hedged answers? Then the honest answers are not available quickly — which means they are not known.
This one has a direct commercial cost. Deals stall in security review, and the sales team reports it as a deal problem rather than a system problem.
The two that mean call this week
Ten of these twelve are chronic. They cost you compounding time and money, and they will still be true next quarter.
Two are acute.
Sign 10 — a core dependency past end-of-life with a blocked upgrade. This is a countdown, not a condition, and you don’t control the clock. Someone else’s disclosure sets your deadline.
Sign 2 — a single person the system cannot survive — when combined with sign 9, no test suite. Either alone is survivable. Together they mean your system’s entire safety mechanism is one human being’s memory, and it has no backup, no redundancy, and a two-week notice period.
If either of those is true today, the right response is a conversation with engineers this week. Our [INTERNAL LINK: /code-risk-review “Code & Risk Review”] is ninety minutes, costs nothing, has two of our engineers on it and no salespeople, and you keep the findings whether or not you ever speak to us again.
How many signs did you count?
| Signs present | What it means | Where to start |
|---|---|---|
| 0–3 | Normal wear. Every system has some of these. | Nothing. Re-check in six months. |
| 4–6 | Real drag, not yet structural. Your team is absorbing it. | [INTERNAL LINK: /code-risk-review “Free 90-minute review”] — get a second opinion cheaply |
| 7–9 | Structural. This is no longer something a team fixes between features. | [INTERNAL LINK: /systems-audit “Systems Audit”] — $18K–$35K, 2–3 weeks |
| 10–12 | The system is now the constraint on the business. | [INTERNAL LINK: /insights/software-project-rescue “Stabilization first”], then decide |
| Either acute sign | Timing is not yours to choose. | Talk to engineers this week |
If you’re between “real drag” and “structural” and want to settle it with evidence rather than opinion, the ten-question rubric in our [INTERNAL LINK: /insights/rebuild-vs-refactor-vs-replace “rebuild vs refactor guide”] is the next thing to run.
The checklist
Here is the whole thing as a checklist you can take into a meeting. No email address, no form, no download gate. Copy it, print it, forward it.
LEGACY SYSTEM WARNING SIGNS — EXECUTIVE CHECKLIST
PEOPLE
☐ 1. New senior engineers take >6 weeks to ship unsupervised
☐ 2. One person the system cannot survive
☐ 3. Engineering attrition above company average, 2+ years
☐ 4. Nobody volunteers to own it in a reorg
PROCESS
☐ 5. Deploys are events, not routine
☐ 6. Estimates unpredictable for similar-sized work
☐ 7. “Too risky to touch” said about a real feature this year
☐ 8. Shipping slowed while headcount grew
CODE
☐ 9. No automated test suite worth the name
☐ 10. Core dependency past end-of-life, upgrade blocked ⚠ ACUTE
☐ 11. Three senior people draw three different architectures
RISK
☐ 12. Security/compliance questionnaires trigger a scramble
SCORE: 0–3 normal · 4–6 drag · 7–9 structural · 10–12 critical
ACUTE: #10 alone, or #2 + #9 together → talk to engineers this week
We don’t gate this. Gating a checklist behind a form would be inconsistent with saying there are no salespeople on our calls, and we’d rather the second claim stay true.
What to do next
Run the checklist this week. It takes ten minutes and a few direct questions to people who already know the answers.
If you counted four or more and want a second opinion that costs nothing, book the [INTERNAL LINK: /code-risk-review “90-minute Code & Risk Review”]. Two of our engineers, your codebase, your worst problem. You keep whatever they find.
The twelve above, grouped as people, process, code and risk. The most reliable early indicators are non-technical: how long a new senior engineer takes to ship unsupervised, whether deploys are routine, and whether shipping has slowed while headcount grew.
Yes, for the majority of signs. Most warning signs surface as organizational symptoms — hiring, attrition, release cadence, deal friction in security review — before they surface as outages. You do not need to read code to observe any of those.
Zero to three. Every system in production accumulates some. The number that matters is the trend: three signs that have been three signs for two years is very different from three that were one sign last year.
A core dependency past end-of-life whose upgrade is blocked. It’s the only one with a deadline you don’t set — the timing is determined by whoever discovers the vulnerability, not by your roadmap.
At that point the problem is structural and won’t be fixed between features. A fixed-scope diagnostic — architecture map, risk register, remediation plan — gives you a defensible answer in two to three weeks, and you own it regardless of who you hire to act on it.
