COBOL Is Dead, Long Live COBOL! Thirty Years of a Departure That Never Happened

The article takes the April 2020 appeal by the Governor of New Jersey — who during the pandemic publicly sought out programmers of the sixty-year-old COBOL technology — and uses its fate to show why thirty years of announced plans to migrate to more modern systems never came to fruition. Using game-theory models (game of chicken, stag hunt, tragedy of the commons) and behavioral economics, the author explains why legacy-system programmers did not become obsolete but rather scarce and better paid — while also pointing out where this optimistic scenario holds and where, conversely, a fatal ending looms, as it did for Kodak.

In April 2020, the governor of New Jersey, Phil Murphy, stepped in front of the television cameras and uttered a sentence that gave the entire IT world pause: we need volunteers who can program in COBOL. The system for processing unemployment benefit claims couldn't keep up with the surge of 362,000 claims in two weeks. A technology from the 1960s, which everyone had been writing off for three decades, turned out to be the backbone of state infrastructure — and no one knew how to fix it.

This sentence could be the beginning of a story about the failure of government IT. But it is the beginning of a story about something more interesting: about what happens to people who sit on top of a technology they've been told for thirty years is dying — and what happens to those who are telling them that.

A language from 1959

COBOL was created in 1959, when computers took up entire rooms and programs were written on punch cards. Grace Hopper — mathematician, rear admiral of the U.S. Navy, and one of the pioneers of computer programming — was present at its birth. At the CODASYL conference, together with Mary K. Hawes and Jean Sammet, she imprinted on the language a vision that was radical for its time: a programming language that even non-programmers could understand. That's why COBOL looks almost like English sentences. MOVE BALANCE TO TOTAL-BALANCE. ADD DEPOSIT TO TOTAL-BALANCE. An accountant could read it and check it.

Banks fell in love with it. So did insurance companies. Government offices. Everyone who needed to reliably process millions of transactions a day. COBOL became the invisible layer beneath the financial system of the Western world — not because it was elegant, but because it worked. And it worked. And it worked.

In the 1990s came Java. Then Python. Then JavaScript and the entire web ecosystem. Every new language brought a wave of pronouncements about the end of COBOL. At conferences it was talked about as a dinosaur. Computer science graduates weren't taught it — why would they be, when the future is in object-oriented programming, in the internet, in mobile phones?

And companies began writing migration plans.

Thirty years of migration plans

The first migration plans appeared around 1995. Big banks hired consulting firms that, for millions of dollars, designed a transition to modern architectures. The PowerPoints had arrows pointing up and to the right. The timelines showed completion in three years.

Three years later, nothing had happened. It turned out that rewriting tens of millions of lines of code that had grown over thirty years and contained business logic no one had ever documented is somewhat more complicated than the PowerPoint suggested.

Around 2000 came the Y2K panic, and COBOL programmers experienced the first wave of paradoxical recognition — the world needed people who understood the old code precisely because no one had replaced that code. The programmers fixed the date formats, were temporarily paid decently, and for a while returned to their terminals. Management breathed a sigh of relief and ordered new migration studies.

Around 2005 came the second wave of migration plans. This time with service-oriented architecture (SOA) and web services. Again PowerPoints, again timelines, again three years. And again: after three years, nothing fundamental had happened. The legacy systems were too intertwined with operations, too critical to be switched off and replaced, and too poorly documented to be rewritten.

Around 2010 it was the cloud. Around 2015, microservices. Around 2020, AI. Each time a new reason why COBOL would finally end. And each time the same result.

The programmers stopped laughing sometime after the third unfulfilled prediction. Not that it wasn't funny — it was still funny. But the laughter shifted from nervous to resigned and then to cynical. When management tells you for the third time that next year is the year, you stop listening. And you start doing exactly what you're doing now — keeping the system running, going home at five, and leaving the strategic visions to those who have time for PowerPoints.

Why it's called a game of chicken

The relationship between management and employees during a technological transition resembles what game theory calls the Chicken Game. Two cars drive toward each other. Whoever swerves is a chicken. Whoever doesn't swerve is a hero. If neither swerves, they both end up in the hospital.

Management wants employees to invest in the transition themselves — on their own time, with their own energy, at their own risk. Employees expect management to come up with a plan, pay for training, give clear guarantees. No one wants to bear the cost. And if no one moves, the legacy system eventually dies with both of them.

The key asymmetry: management has the first-mover advantage. Silence is a strategic move that preserves maximum room for maneuver. "We never promised anything." By not announcing the transition, they don't have to pay for it. By not saying "we're shutting it down," they don't have to deal with resistance. Employees — in the position of the weaker player — are pushed to "swerve" themselves: to retrain at their own expense, to adapt without guarantees.

COBOL programmers had one advantage that most employees in this position can't afford: management swerved repeatedly. Each unrealized migration plan strengthened the employees' position in the next iteration of the game. After three unfulfilled promises, the roles reversed — the chicken became the management that couldn't fulfill its own plans.

But this outcome is not generally transferable. It worked because COBOL systems were critical and irreplaceable. With a mid-sized company's proprietary technology, management can simply "not swerve" by abolishing the department.

Who left, who stayed

Not all COBOL programmers reacted the same way. Some left. They learned Java, C#, Python — retrained in new languages and moved to other teams, other companies, other industries. They mostly did so early, in the 1990s or the early 2000s, when the IT job market exploded and the transition was relatively easy. They vanished from the mainframe world and no one heard from them again — not because they fared badly, but because the story "programmer retrained and does different work" is not a story the newspapers would print.

Others stayed. The reasons varied: some loved mainframes and didn't want to change. Some were ten years from retirement and saw no point in starting from scratch. Some simply didn't have the energy — other things were happening in their lives, children, mortgages, illnesses. And some simply saw what they saw: that the system wasn't going anywhere, that migration plans were management's ritual dance, and that the most sensible strategy is to do your job and not jump out the window after every new wave.

And then there was a third group — the smallest, but ultimately the most successful. People who stayed with COBOL but at the same time learned new things. They understood API design. They learned the basics of cloud architectures. They understood databases, old and new. They didn't become top-tier Java developers — that would have taken years of full immersion. But they became something no one else could be: people who understand the old system and can explain what it does to the people building the new one.

When real migration projects finally came — not PowerPoint ones, but actual ones — this third group became the most valuable resource in the entire process. No fresh graduate, however talented in modern technologies, can read COBOL code from 1987 and say: "This is here because in 1992 the regulatory framework for interstate transfers changed and no one rewrote it, they just added a patch." Google doesn't have this knowledge. Stack Overflow doesn't have it. The person who sat there has it.

The stag hunt: why not everyone retrained

Here a question arises: why did the third group — those who combined old and new — not find more people? The answer is illuminated by a game-theoretic model called the stag hunt. It was described by a logic whose rules all those programmers knew, even though they had never heard of it.

Imagine two hunters. They can hunt a stag together — big prey, but it requires the coordination of both. Or each can catch a hare on his own — small but certain prey. If one hunts the stag and the other slips away for a hare in the meantime, the first one is left with nothing.

In the context of a COBOL team: the stag is a successful transition, where everyone learns new skills and the team survives as a whole. The hare is going on autopilot — doing the minimum, maintaining the legacy, not burning energy on an uncertain project. The problem isn't greed. The problem is fear. Fear that I'll invest my weekends studying a new framework while my colleagues calmly read the news. Fear that I'll be the only one who tried — and I'll be punished the same as everyone else when the cuts come.

The game has two stable solutions. One is better: everyone hunts the stag. The other is safer: everyone hunts the hare. The key detail that distinguishes the model from the more famous prisoner's dilemma: in the prisoner's dilemma, cheating always pays off. Here it doesn't — cooperation is desirable, the only problem is that no one wants to risk going first.

And this is exactly where the role of management is decisive. In the stag hunt there is a solution: someone trustworthy says "we're hunting the stag" and everyone believes him. A coordination signal is enough. But COBOL management never sent this signal — or sent it so many times without backing that no one believed it. The result? Rational employees chose the safer strategy: the hare. Not out of laziness. Out of reasonable caution.

Theory says one more thing: the lower the compensation for the effort, the less it pays to risk the stag. COBOL programmers were typically paid below market level — their specific knowledge didn't have many alternative buyers, so the employer could push wages down. With undervalued wages and zero share in the profit from a potential transition, the stag looks especially scrawny. And the hare especially sensible.

Numbers no one expected

How much COBOL actually runs? The exact number depends on whom you ask. An older Reuters estimate from 2017 cited 220 billion lines of code in production. A Micro Focus/OpenText survey from 2022, based on responses from thousands of IT professionals across 49 countries, estimated the global volume at 800 billion lines. The Open Mainframe Project came up with a figure of 250 billion. Whichever number you take, it's an enormous volume of code that isn't going anywhere. Reuters, in the same analysis, stated that 43% of banking systems rely on COBOL and 95% of payment card transactions pass through it.

And wages? According to ZipRecruiter, the median wage of a mainframe programmer in the U.S. reached $112,000 a year (2024) — roughly $40,000 more than the median for other programmers. Other sources (Glassdoor, Salary.com) cite lower estimates, around $80,000 to $106,000, depending on whether they measure "COBOL programmers" or "mainframe developers." Freelance consultants on legacy systems, according to industry analyses, charge $100–500 an hour. And most organizations using COBOL report that finding qualified developers is their biggest challenge.

How is this possible? The group of programmers shrank for thirty years through natural retirement — but no one replaced the systems they maintained. A disequilibrium market arose: declining supply, stable demand. A classic economic lesson that wouldn't surprise anyone — if management had taken it seriously before it started pleading for volunteers on television.

What happens when the pasture refuses to die

The whole time — for three decades — there was an implicit assumption: COBOL is dying, mainframes are dying, and the people who take care of them are dying with them. It was an assumption so self-evident that no one questioned it. Managers built strategies on it. HR set wages according to it. Graduates chose careers according to it.

Not entirely wrong — COBOL really did lose its share of new development. No one writes new projects in it. In that sense it really is "dying." But it's dying in a way no one expected: as a technology that isn't invested in, but which refuses to disappear because it is an inseparable part of critical infrastructure.

The result? The people who take care of it didn't become useless. They became rare.

The tragedy of the commons — and its paradoxical opposite

In 1968, the biologist Garrett Hardin described the tragedy of the commons: herders share a pasture, each has an incentive to add another cow, but the pasture has a finite capacity. Individually rational behavior leads to collective catastrophe — the pasture is grazed bare.

The legacy system is that pasture. Everyone "grazes" on it — draws their livelihood from maintaining it. The individually rational strategy: do exactly what I know how to do, don't waste time learning new things, collect the paycheck. No one invests in a replacement, because the investment is costly and the benefits — if the transition succeeds — are spread among everyone, including those who didn't lift a finger. Economists call this the free-rider problem: why should I bear the cost when others profit from the result too?

But the COBOL story added an unexpected twist to this analogy: the pasture refused to die. It turned out that the old legacy system is so firmly integrated into the infrastructure that it simply cannot be replaced. And the herders who stayed on the "dying" pasture? While everyone else ran off after new languages and new frameworks, the number of people capable of grazing on this particular pasture shrank dramatically. Demand didn't fall. During the pandemic it turned into panic. The remaining herders didn't grow poor. They grew rich.

Nobel laureate Elinor Ostrom showed that the tragedy of the commons is not inevitable. Small groups with clear rules, mutual trust, and a shared awareness of the state of the pasture can manage common resources. The key condition: the participants must believe that the rules of the game generate higher benefits than their absence. In other words — they must have a reason to cooperate that isn't just altruism.

In COBOL companies, this condition was systematically missing. Management didn't set up rules for the transition. It gave no reason to cooperate. It didn't share information about the actual state of the "pasture." And so the pasture was managed in the most primitive way: everyone grazes on their own and hopes it holds out at least until their retirement.

What management's silence really says

Three decades of migration plans that never worked out left a mark in employees' minds. Not in terms of knowledge, but in terms of trust.

The organizational behavior researcher Denise Rousseau described the concept of the psychological contract— the set of unspoken but mutually understood expectations between employee and employer. Stability in exchange for loyalty. Fair treatment in exchange for reliable work. It's not a legal document. It's something stronger — a shared assumption on which the willingness to do things that aren't in the job description rests.

When an employer breaks the psychological contract — and repeated unfulfilled promises about the future are a breach as loud as thunder — the employee feels entitled to reconsider his share of the commitment too. Not necessarily to leave. But to stop doing anything extra.

Researchers Reichers, Wanous, and Austin described it precisely: cynicism toward organizational change combines pessimism about the probability of success with blaming those responsible for incompetence. And it's contagious. A cynical colleague induces cynicism in others. After three unrealized migrations, the team's cynicism is so deep that a fourth attempt has no chance — not because it's objectively worse, but because no one takes it seriously.

Signaling in reverse

In economics there is a concept of signaling— the idea that actions carry information regardless of whether you want to broadcast it. Michael Spence received the Nobel Prize for this theory (2001, together with Akerlof and Stiglitz).

Management's silence is a signal. Economists Acemoglu and Pischke showed that firms invest in employee training if they plan long-term cooperation with them. The logic is simple: investment in people pays off only when those people stay. A firm that doesn't invest in retraining thereby — whether it wants to or not — broadcasts a message: either it doesn't know what it's doing, or it doesn't count on needing you.

COBOL programmers read this correctly. When a firm talks about migration for thirty years and for thirty years doesn't invest in their retraining, it communicates two things at once: "we don't know how to transition" and "we don't want to pay for it." Under these conditions, the rational response of an employee is to stop investing in the firm and start investing in himself. The modern term for this is "quiet quitting" — but it's a misleading name. It isn't leaving. It's precise adherence to the contract: nothing extra, nothing below.

Why even those who didn't have to stayed

Not all COBOL programmers who stayed did so out of rational calculation. Some stayed because they were held by forces that have little to do with rationality.

Behavioral economics has named a trio of traps that hold people in objectively bad situations.

The sunk cost fallacy — "I've invested too much to leave now." Ten years of studying mainframe architecture, certifications, knowledge of a specific system. Rationally these are sunk costs — they play no role in decisions about the future, because they cannot be recovered. Psychologically they are anchors that drag you to the bottom. Arkes and Blumer (1985) demonstrated that 85% of people continue with a failing project when they are reminded of previous investments — compared to 10% who invest in the same project without any mention of what has been spent.

Loss aversion — we perceive losses roughly twice as intensely as gains of the same size. A new job for more money would have to look twice as good to overcome the fear of losing what one has — peace, routine, familiar colleagues, the feeling of expertise. Even if what one has is objectively undervalued.

Status quo bias — a preference for the current state regardless of the alternatives. The decision to change nothing doesn't seem like a decision. But it is. And it costs concrete money: a 25% wage undervaluation after five years represents 125% of an annual salary in lost income.

There is a simple diagnostic test that reveals whether a person is held in their current position by preference or by illusion: "If someone offered me exactly this job today, at this wage, with this technology — would I accept it?" If not, you're not staying because it's a good job. You're staying because leaving hurts more than staying, even though staying costs more than leaving.

Where the truth is more complicated

The story of COBOL programmers is a great story. Too great — and so it's fair to say where it falls short as a universal template.

First: COBOL survived because it is embedded in critical financial infrastructure for which there is no replacement. Not every legacy technology is this irreplaceable. A mid-sized company's proprietary system is not JPMorgan Chase's mainframe. When management says "we're shutting it down" and means it, it doesn't have to plead for volunteers on television — it just turns off the lights.

Second: the "legacy premium" — the effect where the remaining specialists gain in value because their numbers dwindle — works only with declining supply. If enough colleagues remain on the market, no shortage arises and the price doesn't rise.

And third: there are industries where the technology collapsed along with the people on it. Kodak lost 94% of its employees (from 145,000 at its peak in the 1980s to fewer than 9,000 after its bankruptcy in 2013) not because people didn't want to switch to digital, but because the entire business model of photographic film ceased to exist. The difference between "the technology became obsolete" and "the entire industry disappeared" is the difference between an inconvenience and a catastrophe.

In other words: the COBOL story is a story about how things can turn out well. The Kodak story is a story about how things can turn out fatally. And because a person sitting on top of a legacy technology doesn't know which story he's living in, the best strategy is neither "put your feet up on the desk" (a bet on the COBOL scenario) nor "retrain at any cost" (a bet on the Kodak scenario). The best strategy is to keep both doors open — and to know when to go through which.

The thirty-first year

In 2025, COBOL enters its thirty-first year of a departure that never happened. The mainframes are still running. Legacy systems still process trillions of dollars in transactions. And a new generation of managers — who have never in their lives seen a 3270 terminal — is writing new migration plans.

The programmers who are still left know this. The presentations have different colors, but the arrows point in the same direction — up and to the right. The timelines show completion in three years. Consultants talk about "AI-powered legacy modernization" with the same enthusiasm with which their predecessors talked about SOA, the cloud, and microservices.

Maybe this time it'll work out. AI really can read and translate COBOL code in a way that wasn't possible before. Automatic conversion from COBOL to Java or Python is no longer science fiction — it's a product you can buy. The problem remains the same as always: you can translate the code, but you can't translate the business logic in it if you don't understand it. And only the people who were there understand it.

Phil Murphy is no longer governor — in January 2026 he was succeeded by Mikie Sherrill. New Jersey's unemployment system underwent partial modernization. And somewhere in Trenton, in an air-conditioned, windowless room, a mainframe is still running. COBOL is still running on it. And someone — probably fewer people than five years ago, probably better paid — is still taking care of it.

When they're told again that next year is the year, they'll look at each other, shrug, and get back to work.

Thirty years of experience say they're right.

But the thirty-first year doesn't have to be like the thirty before it.

Radek Bodnár, Claude (Anthropic)

The COBOL statistics draw on data from Reuters (2017), Micro Focus/OpenText (2022), and the Bureau of Labor Statistics. The wage data is based on a ZipRecruiter survey (2024), presented with the awareness that other sources (Glassdoor, Salary.com) cite lower estimates. The game-theoretic models draw on the works of B. Skyrms (Stag Hunt, 2004), A. O. Hirschman (Exit, Voice, and Loyalty, 1970), E. Ostrom (Governing the Commons, 1990), G. Hardin (Tragedy of the Commons, 1968), D. Kahneman and A. Tversky (Prospect Theory, 1979), D. Acemoglu and J.-S. Pischke (Beyond Becker, 1999), and H. Arkes and C. Blumer (The Psychology of Sunk Cost, 1985). The historical data on migration projects is based on publicly available industry analyses.

The concept, structure, and editorial line of the article are the work of the author, who prepared the content outline, established the key theses, and directed the entire creative process. Generative AI (Claude, Anthropic) was used as a tool for research, fact-checking, and fleshing out the author's draft.

The author continuously edited the outputs, verified key findings, and approved the final wording. No part of the text was published without human review. All factual data was verified against the publicly available sources cited in the text.

The procedure complies with the requirements of Art. 50 of EU Regulation 2024/1689 (AI Act) on the transparency of AI-generated content. #poweredByAI