Somewhere inside the servers that process your salary, route your flight, manage your hospital records, and keep the national power grid from tipping into chaos — there is code that nobody alive fully understands.
It was written decades ago, by engineers who have since retired, or died, or simply moved on to other things. It runs on programming languages that universities stopped teaching in the 1990s. It has never been rewritten because it has never failed badly enough to justify the terrifying cost of replacing it. And every year, the people who depend on it — banks, governments, airlines, hospitals, nuclear facilities — quietly pray that today is not the day it finally does.
This is the world of ghost code. And it is far more widespread than anyone in power wants to admit.
COBOL: The Language That Refuses to Die
COBOL — Common Business-Oriented Language — was developed in 1959. To put that in context: it predates the moon landing, the personal computer, the internet, and the smartphone by decades. It was designed to process business transactions on machines the size of rooms, operated by people in suits who called themselves “computer operators” without irony.
In 2026, an estimated 800 billion lines of COBOL are still actively running in production environments worldwide. The global banking system processes approximately $3 trillion in daily transactions through COBOL-based systems. The US Social Security Administration runs on it. So do most airline reservation systems, major insurance platforms, and a significant portion of government benefits infrastructure across Europe, Asia, and North America.
The problem is not that COBOL runs. It runs extraordinarily well — reliable, fast, and battle-hardened by sixty years of continuous operation. The problem is that the generation of engineers who wrote it and understood it at a deep level is vanishing. The average COBOL developer today is over 55 years old. There are roughly one million COBOL programmers still working globally — and almost no one entering the field to replace them.
When they retire, entire institutions will be left operating systems that function like a clock nobody knows how to open.
The Maintenance Trap Nobody Talks About
Here is the perverse economics of legacy software: it is almost always cheaper to maintain broken systems than to replace them — until suddenly, catastrophically, it isn’t.
Replacing a core banking system built on decades of COBOL typically costs between $100 million and $1 billion, takes five to ten years, and carries a failure rate that makes even the most ambitious CTO hesitate. TSB Bank’s botched 2018 migration in the UK locked 1.9 million customers out of their accounts for weeks and ultimately cost the company over £330 million. The Royal Bank of Scotland experienced a similar systems failure in 2012, leaving 6.5 million customers without access to their money for days.
These weren’t anomalies caused by bad planning. They were warnings — sent by systems that were never designed to be replaced, resisting the attempt with everything they had.
The response from most institutions? Don’t replace. Maintain. Wrap the old system in new interfaces, bolt on modern APIs, and hope the core never needs to be touched. It is infrastructure management as denial.
The Security Dimension Nobody Is Saying Loudly Enough
Legacy software is not just an operational risk. It is an active security vulnerability.
Systems built in the 1970s and 1980s were designed in an era before cybersecurity was a concept. They were never written to defend against modern threat actors, ransomware, or state-sponsored intrusion. And because their architecture is opaque even to the organisations running them, security audits are superficial at best — you cannot fully secure a system you cannot fully read.
In 2021, a cyberattack on a Florida water treatment facility exploited legacy control software to briefly alter chemical levels in the water supply. The code running that facility was decades old. The attack was detected — barely, and by accident.
The question security researchers are increasingly asking is not whether another attack will exploit ghost code somewhere critical. It is simply when, and which system, and whether anyone will notice in time.
Is There a Way Out?
The honest answer is: slowly, expensively, and not completely.
AI-assisted code translation — tools that can read COBOL and generate equivalent modern code — has matured significantly in the last three years. Companies like Broadcom, Micro Focus, and a growing number of AI startups are making real progress. But automated translation cannot replace institutional knowledge: the undocumented decisions, the workarounds built on top of workarounds, the functions that behave in ways nobody planned but everyone has quietly designed around.
The deeper fix is cultural. Universities need to teach legacy systems, not just new ones. Governments need to fund modernisation the way they fund infrastructure — as a public safety priority, not an IT budget line. And the industry needs to stop treating technical debt as someone else’s future problem.
Because right now, in the server room of an institution you trust with something important, a program written before colour television became common is processing a transaction that matters to you.
It will probably work fine.
It has worked fine for sixty years.
But nobody alive can tell you exactly why.
