Stop Trying to Kill COBOL. It’s the Only Thing Keeping Your Bank From Collapsing.

You’ve probably been told that COBOL is a dinosaur. A relic. A 60-year-old monstrosity that’s holding your company back from the modern world. Every tech conference, every consultant, every fresh-out-of-college developer with a burning desire to rewrite everything in Rust or Go will tell you the same thing: Replace it. Now.

They’re wrong. And their advice is about to cost you everything.

I spent a decade working with legacy financial systems. Not as a COBOL apologist, but as a skeptic who watched a “modernization” project nearly destroy a major bank. Here’s what nobody tells you: COBOL isn’t technical debt. It’s a technical asset. And the people calling it debt are usually the ones who don’t understand the business logic it carries.

Let me break down the real cost of replacing COBOL — and why the smartest move might be to leave it alone.

The $1 Trillion Illusion

Every major bank, government agency, and insurance company runs on COBOL. The IRS, your local DMV, the social security system, the global banking network — all of them. These systems process trillions of dollars a day without a second thought. They’re not fast. They’re not pretty. But they are deterministic. Every transaction, every calculation, every business rule has been tested by decades of use. Bugs are rare. The logic is ironclad.

When a consultant pitches a rewrite, they promise speed, agility, and lower maintenance costs. They show you a Gantt chart and a fancy dashboard. What they don’t show you is the graveyard of failed migrations. Replacing a COBOL system is not a technical challenge. It’s a knowledge extraction problem — and most organizations fail.

I saw this firsthand. A major bank decided to replace its core COBOL system with a modern Java stack. Three years and $200 million later, they had a system that was slower, more expensive to run, and rife with bugs. The kicker? The new system lost the ability to handle a specific edge case for international wire transfers — a rule that had been in place for 30 years. Nobody had documented it. It was buried in the COBOL code. The bank nearly triggered a cross-border settlement failure that would have cost them billions.

Why Modernization Is a Resume-Driven Trap

Here’s the ugly truth: most developers don’t want to maintain COBOL. It’s not sexy. It doesn’t look good on a LinkedIn profile. So they pitch a rewrite — not because it’s the right decision, but because it’s the career-enhancing one. Modernization is often a resume-driven development trap where engineers lack the domain-specific business knowledge to safely replace what already works.

One commenter on the original thread nailed it: “I worked at the US Army ATCOM base migrating databases and programs from an IBM Mainframe to Windows 3.X using Access and SQL Server and Visual BASIC. We kept the IBM Mainframe and HP/UX databases and programs to compare to the new ones. If the results were the same, we were good enough to switch.” That’s the right approach — keep the old system running as a reference. But most companies skip that step. They assume the new system will be correct. It never is.

The Hidden Cost of Fragility

Modern systems are more flexible. They’re also more fragile. COBOL runs on a mainframe — a single, tightly controlled environment. It’s obsolete, but it’s also impenetrable. Modern systems run on distributed microservices, Docker containers, Kubernetes clusters, and cloud APIs. Each layer adds complexity, and each layer introduces failure points. The irony is brutal: You’re replacing a system that never crashes with one that will crash regularly — just faster.

And the cost? A 2023 study estimated that maintaining COBOL costs about $1–2 billion annually across the US government. A full rewrite? Easily $100 billion or more — and that’s before you account for the six-figure salaries of Python developers who don’t understand how a GOTO loop works. The math doesn’t work.

What Should You Actually Do?

Stop pretending COBOL is a problem to be solved. Treat it as a foundation to be preserved. Encapsulate it. Put an API layer on top. Let the old system do what it does best — run deterministic business logic — and build new features around it. This is called the “strangler fig” pattern, and it’s the only approach that consistently works. Keep the COBOL core alive. Modernize the edges. Don’t touch the heart.

The next time a developer tells you to rewrite COBOL in Rust, ask them one question: “Do you understand the business rules that keep our bank from collapsing?” If they don’t, you’re about to make a very expensive mistake.