Ask around about COBOL and you'll hear the same handful of claims regardless of who's talking: nobody's learning it, it only exists inside a handful of ancient banks running out the clock, the tooling stopped evolving decades ago, and the popularity charts prove the whole thing is dying. Some of that was true at some point. Very little of it holds up against what's actually documented right now. This is a walk through five of the most common claims, checked one at a time against training numbers, vendor investment, industry data, and a widely cited popularity index, rather than against the version of COBOL that lives in most people's heads.
Claim 1: Nobody's learning it anymore
This one usually gets stated as settled fact, and it isn't. IBM alone has run COBOL training programs aimed at exactly this gap for more than a decade, and the throughput isn't small.
That figure sits in tension with what practitioners actually say when you ask them directly, and the tension is worth sitting with rather than resolving too quickly in either direction.
“There are also far fewer people who remember how to maintain these old systems. If they belong to a bank or similar, they are probably still vital to its running.”
Campbell Ritchie, on "Is it worth learning COBOL?", CodeRanch forum
Both of those things are true at the same time, and reconciling them tells you more than either one alone. The pipeline that's actually training new COBOL developers exists, but it's concentrated inside specific employer and vendor programs, IBM's own courses, bank-run apprenticeships, mainframe-vendor bootcamps, rather than spread across university computer science departments where a hiring manager might expect to see it. That makes it functionally invisible from outside those programs while still being real in aggregate. "Nobody's learning it" isn't accurate. "The people learning it aren't learning it where you'd think to look" is closer to the actual shape of the problem, and it's a different problem to solve: it's a visibility and recruiting-channel issue, not an extinction-level pipeline collapse.
That distinction matters for what a shop actually does about it. A pipeline collapse has no real fix short of the language itself becoming more attractive, which isn't a lever any individual employer controls. A recruiting-channel problem is a much more tractable thing to work on: it means the fix looks less like waiting for a new generation to fall in love with COBOL on their own and more like a company deciding to run its own internal training track, the way IBM's own programs and a number of large banks and insurers already have, rather than posting a job requisition for five years of COBOL experience and being surprised when almost nobody qualifies. The shops treating this as a training investment they control are, by definition, not experiencing the shortage the same way the shops waiting for a ready-made hire are.
Claim 2: It's just old banks running out the clock
Banking is the industry COBOL gets associated with by default, largely because it's the industry with the most publicly reported incidents and the clearest historical link to the language. It is nowhere close to the only industry actually depending on it.
The insurance figure is the one worth actually stopping on, because insurance runs on almost exactly the computational pattern COBOL was built for and mainframes still do well: enormous overnight batch runs recalculating premiums, processing claims, applying policy terms, and reconciling accounts across millions of policyholders, all of it correctness-critical and heavily regulated in ways that make a rushed rewrite genuinely dangerous rather than just inconvenient. A claims-processing error that silently miscalculates a payout doesn't announce itself the way a website outage does; it surfaces months later, in an audit, or a lawsuit, or a regulator's inquiry, by which point the cost of getting it wrong has compounded well past what a slower, more careful migration would have cost. That's the same underlying logic that keeps COBOL in banking, applied to an industry that gets almost none of the press coverage banking does. Airlines land in the same bucket for a related reason: reservation and fare systems that have to stay correct and available around the clock, across decades of accumulated business rules, are exactly the kind of system organizations are least willing to gamble on a full rewrite of.
What ties banking, insurance, and airlines together isn't the industry label, it's a shared operational shape: a large volume of interdependent transactions that all have to reconcile to a single correct state by a hard deadline, whether that deadline is "before branches open" or "before the next flight departs." That shape is what COBOL and mainframe batch processing were built to handle well, and it shows up in plenty of places the caricature never mentions: pension administration, freight and logistics settlement, government benefits processing, utility billing. The "just old banks" framing survives mostly because banking incidents make the news and claims-processing backlogs at an insurer don't, not because banking is actually where the dependency is concentrated.
Claim 3: There's no real tooling left, it's all green screens and TSO
This claim was closer to true a decade ago than it is now. The clearest counter-evidence isn't a modernization vendor's marketing page, it's what IBM itself has been quietly building directly into its AI product line.
“WCA for i has been modeled off other WCA products, including Watsonx Code Assistant for Z, which the mainframe group developed to understand and generate COBOL, the primary language used on the System Z.”
IT Jungle, on IBM's watsonx Code Assistant line
Read that sentence for what it actually implies rather than skimming past it: IBM built a large-scale AI code assistant with COBOL comprehension as its founding use case, not as an afterthought bolted onto a more fashionable language, and it then used that same COBOL-trained product as the template for extending AI tooling to other languages in its portfolio. That is not the behavior of a vendor treating COBOL as a maintenance-mode language to be quietly wound down. It's the behavior of a vendor betting that understanding and generating COBOL, at scale, is valuable enough to build core infrastructure around in 2023 through 2025, decades after the language was supposedly finished evolving. Whatever the green-screen stereotype captures about the interfaces some COBOL shops still run day to day, it says nothing accurate about where the tooling investment is actually going.
It's also not just an AI story. The unglamorous end of the tooling stack has moved further than the stereotype allows for too: COBOL source living in Git alongside everything else a shop maintains, changes going through the same pull-request and code-review workflow as any other codebase, and automated pipelines compiling and unit-testing COBOL changes before they ever reach a mainframe LPAR, are now normal practice at shops that have invested in modernizing their process rather than their language. None of that requires touching a single line of the COBOL itself. It just means the day-to-day experience of changing COBOL safely looks a lot more like the day-to-day experience of changing any other production codebase than the 3270 terminal stereotype suggests, and that gap between the stereotype and the actual working environment is exactly what makes the green-screen claim feel outdated to anyone who's worked inside a shop that's made the investment.
Claim 4: The popularity numbers prove it's dying
That range gets cited as proof of decline, and read one way it is: a language that ranked eighth by search and discussion volume in 2001 has spent the better part of two decades falling, not rising, on the same measure. But a popularity index like TIOBE is measuring something specific and narrow: how much people are searching for, writing tutorials about, and discussing a language right now, which tracks new-project interest far more than it tracks what's actually running in production. It's a reasonable proxy for where developers are choosing to spend their curiosity. It is a poor proxy for where the money and the transaction volume already are.
Both of those numbers are accurate at the same time, and the contradiction between them is the actual myth worth retiring, not either statistic on its own. COBOL genuinely is unpopular by the measure of where new development interest is going. It is simultaneously enormous by the measure of what's already running and processing money today. Treating a ranking built for measuring novelty as if it also measures installed-base dependency is the mistake, not the ranking itself, and it's a mistake that specifically favors whichever language is currently fashionable over whichever language is currently load-bearing.
Claim 5: If you're maintaining it, you should be pushing for a rewrite
This is the claim with the most genuine nuance in it, because it isn't simply false the way the others are. Rewriting sometimes is the right call. The honest problem is that "rewrite it" gets treated as an obviously correct default rather than a real tradeoff, and the people actually running these systems don't see it that cleanly.
That's not a contradiction in the data, it's a description of an actual split opinion among the people with the most direct stake in the answer. A majority see the mainframe, and by extension the COBOL running on it, as a strategic asset worth continuing to invest in rather than a liability to be escaped. A meaningful minority genuinely worry about the operational risk of keeping it. Neither group is wrong on its face; they're weighing the same tradeoff, the cost and risk of touching a correctness-critical system that already works against the cost and risk of leaving it exactly as it is, and landing in different places depending on their own system's specific condition, their own team's bench strength, and how much of that system's behavior is actually documented anywhere. "You should obviously rewrite it" collapses a genuine, contested engineering judgment call into a slogan. The practitioners closest to the decision aren't making it that way, and neither should anyone advising them.
The honest version of this claim isn't "never rewrite" or "always rewrite," it's "the answer depends on what you're actually looking at." A COBOL system with thin documentation, no one left who understands its edge cases, and a business that's changed shape around it is a genuinely different risk profile than a well-understood, actively maintained system that just happens to be old. Collapsing both of those into a single universal recommendation, in either direction, is where the actual myth-making happens. The practitioners surveyed above are living with that distinction daily, which is exactly why their answers split instead of converging, and it's a far more honest starting point for anyone staring at a maintenance backlog than a one-line verdict borrowed from whichever side of the debate happened to be loudest that week.
Where this leaves you
- COBOL training is real and substantial in volume, IBM alone has trained over 180,000 developers, but it's concentrated inside employer and vendor programs rather than visible general education channels, which is a recruiting problem, not a pipeline collapse.
- Banking gets the headlines, but 8 of the top 10 global insurers and 4 of the top 5 airlines depend on the same mainframe and COBOL infrastructure for the same underlying reason: large, correctness-critical batch processing that a rushed rewrite puts genuinely at risk.
- Tooling investment hasn't stalled. IBM built its watsonx AI code assistant line around COBOL comprehension first, then used it as the template for other languages, which is a bet on relevance, not a maintenance afterthought.
- Popularity indexes like TIOBE measure new-project interest, not production dependency; COBOL scores low on one and remains enormous on the other, and conflating the two produces most of the "it's dying" headlines.
- Whether to maintain or rewrite a given COBOL system is a genuine, contested tradeoff even among practitioners who run these systems for a living, not a settled question with one obviously correct default answer.
None of this argues that COBOL is thriving in the sense a rising, fashionable language thrives. It argues something narrower and more accurate: the specific claims used to dismiss it mostly don't survive contact with the numbers behind them, and the people who actually depend on it for a living are having a more careful, more divided conversation about its future than the caricature gives them credit for.
Try the Skills Gap Assessment tool →Read the COBOL modernization guide →