Modernization. You Keep Using That Word.
Mark Schettenhelm, principal product manager at BMC, notices that when people talk about modernization, they often mean migration—to their own detriment
In The Princess Bride, Inigo Montoya delivers one of the most quotable lines in cinema history: “You keep using that word. I do not think it means what you think it means.” He was talking about “inconceivable.” But if Inigo were attending mainframe industry conferences in 2026, he might find an equally apt target: “modernization.”
Spend any time in conversations about enterprise IT strategy and you will hear the word constantly. Modernize the mainframe. Modernization is the priority. We have a modernization roadmap. But listen carefully to what people actually mean when they say it, and a troubling pattern emerges.
For many IT leaders—particularly those whose careers were built on distributed systems—”mainframe modernization” is a polite way of saying “get off the mainframe.” The word sounds forward-looking and responsible. The intent, more often than not, is migration.
This matters. Because if you are using “modernization” to mean migration, you are almost certainly not doing the thing that would actually help your organization, which is modernizing the applications that run on your mainframe.
The Platform Is Not the Problem
Before we can have an honest conversation about modernization, we need to separate two things that routinely get conflated: The mainframe as a platform, and the applications running on it.
The IBM Z platform is genuinely modern. It runs Linux. It supports containers and APIs. It integrates with hybrid cloud architectures. The latest IBM Z systems deliver the kind of security, availability and transaction throughput that distributed platforms spend enormous effort and money trying to approximate. If you evaluated mainframe hardware on its technical merits today, you would not call it legacy. You would call it competitive.
What can legitimately be old, sometimes very old, are the applications running on it. And here is the paradox at the heart of mainframe management: The same architectural durability that makes the platform exceptional is the reason applications written 40 years ago can still run today. They process payroll. They clear financial transactions. They calculate claims and premiums. They work, which means there has been little urgent pressure to improve them.
But “works” and “well-maintained” are not the same thing. An application that has not been significantly updated in three decades carries three decades of accumulated complexity—business logic, data access and presentation concerns layered on top of each other in ways that no single person alive fully understands. Undocumented rules. Workarounds for problems that no longer exist. Functions that were added over the years without ever restructuring the whole. These are not small, focused programs. Many of them are monolithic behemoths of hundreds of thousands of lines where changing one thing can break something unexpected somewhere else.
That is a real problem. It is just not a platform problem.
How the Wrong Diagnosis Became Conventional Wisdom
It is not hard to understand how the migration narrative took hold. If you came up through distributed systems, if Java and microservices and cloud-native development are your native language, then a 40-year-old COBOL monolith looks like evidence of a platform that time left behind. The prescription seems obvious: Rewrite it in something modern, move it somewhere modern, and the problem goes away.
This reasoning is understandable. It is also wrong. And the COBOL-to-Java conversion wave of recent years has demonstrated the cost of that error at scale.
The pitch is appealing on its surface. Java is modern. There is a large pool of Java developers. The code will run off the mainframe, reducing platform costs. What could go wrong?
Plenty.
The fundamental problem with these aging applications is not the language they are written in. The problem is that they are not understood. Translating COBOL to Java does not resolve that problem; it moves it.
You still have the same tangled business logic, the same undocumented rules, the same implicit dependencies. You have simply expressed them in a different syntax, handed them to developers who are equally unfamiliar with what the code actually does, and added the cost and risk of the conversion itself. The track record of large-scale COBOL-to-Java migrations is littered with projects that ran over time, over budget, and produced systems that behaved differently from the originals in ways that took years to untangle.
The fear of changing these applications is not irrational. It is a rational response to complexity that was allowed to grow unchecked. The answer to that fear is not a wholesale rewrite. It is comprehension.
What Deferred Modernization Actually Costs
Here is the harder part of the story. Because so many organizations decided—implicitly or explicitly—that the mainframe was a transitional platform to be replaced when the time was right, they stopped investing in the applications running on it. Why refactor a monolith you are planning to migrate? Why break it into modular components, introduce automated testing, document the business logic, if the whole thing is going to be rewritten next year?
Next year became next year became next year. And IBM’s architecture, ever accommodating, kept running the applications faithfully. The consequences of inaction were deferred. But they were not avoided. What accumulated instead was more complexity, more retired developers who took institutional knowledge with them, and more business-critical logic buried inside programs that fewer and fewer people dared to touch.
The organization kept telling itself a story about modernization—a migration that was always on the roadmap, always just around the corner—while the actual work of improving the applications never happened. The word was used constantly. The thing it should have meant was not done.
What Real Modernization Looks Like
The organizations that got this right asked a different question. Not “How do we get off the mainframe?” but “How do we make our mainframe applications easier to understand, change and deliver?”
That question points toward achievable work. It means using static analysis tools to map the structure of complex programs, building the comprehension that developers need before they can safely make changes. It means identifying the natural seams within monolithic applications and extracting discrete, callable components: smaller, focused programs with clear inputs and outputs that can be understood, tested and modified with confidence. It means introducing modern version control, automated pipelines and development workflows that bring mainframe delivery into alignment with how the rest of the organization ships software.
This kind of work produces immediate, tangible results. A developer who was afraid to modify a 100,000-line COBOL monolith becomes willing and able to work on a well-structured 8,000-line module. Release velocity increases. Risk decreases. The business gets the responsiveness it was waiting for—from the mainframe, not by replacing it.
None of this requires abandoning COBOL. The language is more capable than its reputation suggests, and the tooling available to mainframe developers today—including AI-assisted code explanation, automated structure analysis and modern IDE integration—is far beyond what was available even five years ago. What it requires is treating the mainframe estate as something worth investing in, rather than something to be tolerated until a migration that keeps receding into the future.
Choosing the Right Word
Inigo Montoya’s frustration with imprecise language was, at its core, a frustration with consequences. Words shape decisions. If your organization uses “modernization” to mean migration, you will make migration decisions. The applications that actually need attention will continue to accumulate complexity while the roadmap points somewhere else.
The mainframe is not legacy. Some of the applications running on it are. That distinction is not pedantic; it is the difference between solving the right problem and solving the wrong one.
Use the word carefully. Make sure it means what you think it means.
