The COBOL Programmer Shortage

Part 2 established the scale of the COBOL footprint — hundreds of billions of lines, concentrated in the systems that run finance, insurance, and government. This part is about the number that turns that footprint from a fact into a deadline: the people who understand it are retiring, and the pipeline behind them is thin. The COBOL programmer shortage is the single most-cited reason enterprises modernize, and it is worth understanding precisely — because the popular version of the story is half wrong.

The numbers, sourced

Two figures, taken together, define the problem:

The average age of a COBOL developer is roughly 58, with about 10% of the COBOL workforce retiring each year. — IBM, reported via Fujitsu, 2020

Hold those next to the installed base from the last part — 220 billion to 800 billion-plus lines (Reuters via IEEE Spectrum, 2017; Micro Focus, by 2022) — and the structure of the crisis is plain. A vast, load-bearing body of code is maintained by a workforce that is both old and shrinking on a predictable schedule. A 10% annual retirement rate means that, absent replacement, the maintainer population roughly halves about every seven years. The code is not going anywhere. The people who understand it are.

Why this is the real driver — not a deadline

It is tempting to frame COBOL modernization as racing a vendor cutoff, the way you might race a Windows Server end-of-life date. That framing is wrong, and using it damages your credibility with the people who run these systems. COBOL is not end-of-life. IBM actively maintains and ships modern compilers, and the ISO standard was revised as recently as 2023. No one is pulling support next year.

The pressure is more durable than any deadline, precisely because it is demographic rather than contractual. A vendor can extend a support date; a vendor cannot un-retire your experts. The shortage is the rare modernization driver that gets monotonically worse with time and cannot be negotiated away. That is what makes it the honest centerpiece of the business case — and why the BOFU guide on COBOL and mainframe migration leads with the skills cliff rather than a fake expiry.

What the shortage actually is

The popular version — “nobody knows COBOL anymore” — is not quite true, and getting it precise changes what you do about it. COBOL developers still exist. You can hire them, and a competent programmer can learn COBOL’s syntax in a matter of weeks; the language is verbose but not conceptually hard. So if the syntax is learnable and people are hireable, where is the shortage?

It is in the context, not the code. The scarce asset is not the ability to read PERFORM and PIC clauses. It is the institutional knowledge of your estate:

• why the interest calculation rounds the way it does, and which regulation that satisfies;
• which downstream batch job quietly depends on a particular record type being handled a particular way;
• which of the 4,000 programs are actually still reached, and which are dead code no one dares delete;
• the reason a fix that “obviously should work” broke production in 2009.

That knowledge took decades to accumulate and lives in a handful of heads. It was never documented, because the people who had it were busy keeping the system running, not writing it down. When they retire, it leaves with them — and a new hire fluent in COBOL syntax inherits the code without the context, which is a more dangerous position than it sounds.

The cost of a thinning bench

The shortage does not announce itself with an outage. It shows up first as friction and risk that compound quietly:

• Change slows down. Every modification has to route through the few people who understand the affected area, and they become a bottleneck on the entire roadmap.
• Risk concentrates. When one or two people are the only ones who can safely touch a critical system, the organization is one resignation or illness away from being unable to change it at all.
• Costs rise. Scarce specialists — often retired contractors brought back at premium rates — are expensive, and the price only moves one direction as the bench thins.
• Knowledge decays silently. Each retirement removes context that was never captured, so the next migration is harder than this one would have been. Delay does not hold the problem steady; it makes it worse.

This is the run-the-business tax in its sharpest form. Surveys put the share of IT budget spent keeping existing systems running at roughly 55% (Deloitte Global CIO Survey, 2020) — and on a COBOL estate maintained by a shrinking bench, that share is both high and fragile.

What to actually do about it

The shortage argues for a specific response, and it is not “panic-migrate everything.” It is to capture the knowledge while the experts are still here to validate it. The most valuable thing a retiring COBOL expert can leave behind is not more years of maintenance — it is their understanding, written down and verified, in a form the next team can own.

In practice that means reading the COBOL, copybooks, and batch flows and turning them into living specifications: the call graph, the data flows, the business rules, the edge cases, captured as artifacts the team reviews and keeps. Done while the experts remain, this turns retirement from a knowledge-loss event into a knowledge-transfer event. Done after they leave, it becomes archaeology — slower, less certain, and dependent on reverse-engineering behavior from code and production logs alone.

This is also where the urgency and the modernization sequencing meet. You do not have to migrate a workload this year to benefit from capturing its knowledge this year. The capture is valuable on its own, it de-risks whatever migration eventually happens, and it is the one task whose cost rises with every retirement you wait through. Part 7 covers how that capture is actually done.

Urgent is not the same as universal

The shortage makes the case urgent; it does not make it universal. A stable workload that almost never changes, maintained by a team that is not about to retire, is not made more urgent by an industry-wide demographic trend. The figure that matters is local: if the two people who understand a critical system are within a few years of leaving, the global average age is beside the point — your own clock is what counts. Use the macro numbers to calibrate, then make the call on your own bench and your own systems.

Where this leads

The footprint is huge, the workforce is thinning, and the knowledge is walking out the door. That is the pressure. The next four parts are about the response — how you actually move COBOL onto a modern stack without losing what makes it correct. Part 4, COBOL Migration: The Complete Guide, lays out the core decision every COBOL program faces — convert, rewrite, or replace — and the data-structure realities that make that decision harder than it first appears.