Why Is COBOL Talent Disappearing, and What Should You Do About It Now?
You probably can’t name the three people who keep your core systems running. But your CFO should know who they are, because if two of them retire in the same quarter, you have an operational crisis, not an HR vacancy.
COBOL didn’t go away. Reuters estimated there were 220 billion lines of it still in production, running 43 percent of the world’s banking systems and 95 percent of its automated teller machines, plus insurance policy systems and government benefits programs. The code is fine. The problem is the people. The generation that wrote and maintained it is retiring, the pipeline of replacements barely exists, and most organizations are treating this as a problem for next year’s budget.
It isn’t. It’s a risk you’re carrying right now, and it gets more expensive to address the longer you wait.
Why the Talent Pool Is Drying Up
The demographics are unambiguous. As one analysis in AFCEA’s SIGNAL magazine put it, the majority of COBOL experts range in age from 50 to 70 years old and “are not only getting older but are also rapidly leaving the workforce.” A meaningful share are already past traditional retirement age and stay on largely because no one can replace them. As that generation exits over the coming years, they’re taking decades of undocumented institutional knowledge with them.
The replacement pipeline isn’t keeping up. Universities stopped teaching COBOL as a core subject decades ago. New computer science graduates want to work in Python, TypeScript, and cloud-native stacks, not on green-screen terminals attached to systems older than they are. The handful of younger engineers who do learn COBOL know they’re rare, and they price accordingly.
So you face a squeeze from both ends: the supply of people who can maintain your systems is shrinking, and the cost of the ones who remain is climbing. Some organizations have been forced to bring retirees back as contractors at multiples of their old salaries, which works right up until the contractor stops answering the phone.
The Risk You’re Actually Carrying
The real exposure isn’t “we might struggle to hire.” It’s concentrated, undocumented, single-point-of-failure knowledge.
Key-person risk. When one engineer is the only person who understands how the nightly settlement batch works, that engineer is a single point of failure for a system that moves money. A car accident, a sudden retirement, or a competing offer becomes an enterprise incident.
Undocumented business logic. Decades of regulatory changes, edge cases, and workarounds live in the code and in people’s heads, not in any document. When the people leave, that knowledge becomes unrecoverable archaeology. You don’t find out what was missing until something breaks and no one can explain why.
Rising cost of every change. As expertise thins out, even routine maintenance, a new regulatory report, a rate change, a date-format fix, takes longer, costs more, and carries more risk because fewer people can review the work.
Audit and regulatory exposure. For banks, insurers, and government agencies, “we depend on two people who could retire tomorrow and we can’t fully explain our core system” is increasingly something examiners and auditors ask about directly.
What Doesn’t Work
Before the options that do work, two that don’t.
Hoping to hire your way out. The talent isn’t there in the volume you need, and the people who exist are expensive and already employed. Building a COBOL hiring strategy in 2026 is planning around a resource that’s actively disappearing.
Doing nothing until it’s urgent. The cheapest, lowest-risk time to capture knowledge is while the experts are still on staff and willing to help. The most expensive time is after they’ve left, when you’re paying premium contractor rates to reverse-engineer your own systems. Every quarter you wait moves you from the first situation toward the second.
The Three Things That Actually Work, Done Together
The organizations that handle this well don’t pick one strategy. They run three in parallel, because each one buys down a different part of the risk.
1. Capture the knowledge before it walks out the door. This is the most urgent move and the one most often neglected. While your experts are still on staff, document the systems, the business rules, and the operational tribal knowledge. AI has made this dramatically more feasible: modern models can read COBOL, JCL, and copybooks and generate first-draft documentation, dependency maps, and data-flow explanations in days rather than the months it would take by hand. The right workflow is AI generates the draft, your remaining expert validates and corrects it. In IBM’s documented engagement with Egypt’s social-insurance agency, AI-assisted tooling cut the time developers needed to understand complex COBOL applications by up to 79% — and, more importantly, it gets the knowledge out of one person’s head while that person is still around to confirm it’s right.
2. Selectively modernize the highest-risk systems. You don’t have to move everything, and you shouldn’t try to all at once. Identify the systems where the staffing risk is highest and the modernization is most tractable, and move those off COBOL first using an incremental, strangler-fig approach rather than a big-bang rewrite. The goal is to shrink the surface area that requires scarce COBOL skills, prioritizing the pieces that are both painful to staff and reasonable to migrate. Every capability you move to a modern stack is one fewer thing that depends on a retiring expert.
3. Train and cross-skill, as a bridge. Bring younger engineers alongside the experts so some knowledge transfers directly, and cross-train so no single system has only one person who understands it. Be realistic about this: you’re not going to manufacture a new generation of career COBOL developers. Training is a bridge that keeps the lights on while you execute the first two strategies. Treat it as buying time, not as a permanent solution.
How to Sequence This Over the Next 12 Months
Here’s a practical order of operations if you’re starting from a standing exposure.
First, assess the exposure honestly. Map which systems depend on which people. Identify the single points of failure, the engineers within a few years of retirement, and the systems with the thinnest documentation. You’re building a risk register, not a project plan, yet. Most leadership teams are surprised by how concentrated the risk actually is.
Second, triage by risk, not by size. A small, undocumented program that one near-retirement engineer maintains and that touches money or compliance is a higher priority than a large, well-understood, stable system. Sort by “what happens if this person leaves tomorrow,” not by lines of code.
Third, start knowledge capture immediately on the highest-risk systems, using AI-assisted documentation plus expert validation, while you simultaneously plan selective modernization of the systems that are both high-risk and movable.
Fourth, set a modernization cadence that retires COBOL-dependent surface area steadily rather than in one heroic push. Aim to reduce, not eliminate, your dependency on scarce skills every quarter.
This is exactly the kind of work we take on at Particle41 for banks, insurers, and government agencies: senior engineers who can read and document legacy COBOL, AI tooling that accelerates the knowledge capture, and an incremental modernization plan that shrinks key-person risk one system at a time. The hardest part is rarely the technology. It’s starting before the retirement letters arrive.
The disappearing-talent problem doesn’t announce itself with a crisis. It announces itself quietly, with one retirement, then another, until one day a routine change can’t get made because the only person who understood it is gone. The time to hedge that risk is while you still have the people who can help you do it.