Legacy Is a Sales Word

I’ve sat through a lot of enterprise sales pitches over the years. You can always tell when the salesperson doesn’t actually understand what they’re selling—they get this glazed look when you ask a technical question, then pivot back to the script. “But have you considered the total cost of ownership?”

There’s one word that always makes my ears perk up: “legacy.”

“You’re still running a mainframe? That’s legacy technology. You need to modernize.”

Nine times out of ten, the person saying this couldn’t tell you what a mainframe actually does. They just know it’s old, and old is bad, and they have a shiny new thing to sell you.

Here’s the thing. That mainframe? It’s processing a million transactions a day. Has been for twenty years. Doesn’t go down. When’s the last time you said that about a Kubernetes cluster? (I’ll wait.)

“Legacy” isn’t a technical term. It’s a sales term. It means “technology we can’t sell you more of.”

The big iron that won’t quit

Banks run on mainframes. Airlines. Insurance companies. The stuff that absolutely cannot fail.

And look, these aren’t organizations that are stuck in the past because they don’t know any better. They’ve evaluated the alternatives. They’ve done the math. They keep running the mainframe because it works.

A z16 can handle 25 billion transactions a day. Measures uptime in decades. The code running on it has been tested by twenty years of production traffic. Every edge case, found and fixed. Every weird regulatory requirement, encoded somewhere in that COBOL.

You want to replace that with microservices? I mean… good luck with that.

The actual problem (and it’s not COBOL)

Okay, the COBOL skills gap is real. The people who built these systems are retiring. That’s a legitimate concern.

But the answer isn’t always “rewrite everything in Java.” Sometimes it’s “train new people on the systems you have.” Document them. Understand them. Invest in maintaining them.

That’s less exciting than a modernization project, I get it. No vendor to bring in. No big contract to sign. Just the unglamorous work of keeping things running.

Which is maybe why nobody’s selling it.

A quick translation guide

When someone calls your system legacy, here’s what they might actually mean:

• “Legacy” = “It works, but we can’t bill hours on it.”
• “Technical debt” = “Code I didn’t write.”
• “Modernization” = “Replacing something that works with something unproven.”

I’m not saying never migrate. Sometimes the old system really is holding you back. Sometimes the business has changed and the old architecture doesn’t fit. Sometimes you genuinely can’t hire people to maintain it.

But be honest about why you’re migrating. Is it because the current system can’t do the job? Or because someone convinced you to be embarrassed by it?

What’s actually interesting

Here’s the thing I find funny. While everyone’s been writing off mainframes as dead tech, IBM’s been quietly modernizing them. z/OS runs Linux containers now. You can write COBOL in VS Code. There are actual young developers learning this stuff—some ironically, some because they figured out that “dying skill” plus “critical infrastructure” equals job security.

The mainframe isn’t going anywhere. It’s just not fashionable. And fashion is a terrible way to make infrastructure decisions. (Same reason the Unix philosophy keeps winning—boring, stable interfaces beat shiny new ones over time.)

The mainframe doesn’t care about your org chart. It doesn’t need a sprint retrospective. It just processes transactions.

That’s not legacy. That’s infrastructure.

What’s your “legacy” system that refuses to die? I’d genuinely like to hear about it.