THE LINUX FOUNDATION PROJECTS
Blog | Mainframe Modernization | Mentorship

Summer Mentorship 2026: When We Say “Modernize the Mainframe,” What Are We Actually Promising?

By | July 27, 2026

A midpoint reflection and survey from the Open Mainframe Project Summer Mentorship 2026 written by Linisha Bansal, guided by Sarah Julia Kriesch

I came into this mentorship as a newcomer to the mainframe world. That has turned out to be a strange kind of advantage: when you are new, you have not yet absorbed the assumptions everyone treats as settled, so you end up asking out loud the questions experienced people have quietly stopped asking.

A few weeks in, the shape of the work came from my mentor, Sarah Julia Kriesch, how mainframe modernization actually fits together, which tools and which questions were worth chasing, and a Linux environment on real IBM Z hardware to try open-source COBOL myself. She also brought me into the conversation that shaped this post most: a call, alongside her, with Simon Sobisch, who has led the GnuCOBOL project since 2017. I came in asking which open-source compiler was “better.” I left understanding that the real question was older and harder, how any tool, old or new, earns the trust to be handed code it did not write.

Put concretely: when a program that has run correctly for forty years is moved, to a new compiler, a new platform, or a new language entirely, what tells us it still does exactly what it did before?

The promise, as it is usually told

The story driving today’s modernization push is familiar. Enormous amounts of COBOL run the core of banking, insurance, healthcare, and government. The people who wrote it are retiring, and the talent pool fluent in newer known languages and cloud-native tooling is far larger than the one fluent in COBOL and the environment around it. Artificial intelligence has stepped into the center of that story: the current generation of tools promises to read decades-old code, explain it in plain language, convert it to Java, and generate tests showing the new behaves like the old. For an organization staring at millions of lines of undocumented logic, the appeal is obvious.

And some of the promise is real. Even partial help with code that no living person fully remembers has value. But a conversion inherits every gap in the understanding that produced it: whatever an AI misses when it reads a program becomes what it silently drops when it rewrites one. So the question underneath the promise is not whether AI helps, it is how far its understanding actually reaches, and what happens to the parts it never saw.

What full understanding would even require

Part of what makes that question hard is that a mainframe program’s meaning does not live in its source text alone. Its numbers may be stored in packed decimal and its characters in EBCDIC; its files are often indexed structures the operating system itself understands; its transactions may be coordinated by a transaction manager (CICS); its execution is sequenced by job control that assumes a particular operational world. A reader, human or machine, that sees only the COBOL sees only part of the program. Which means an AI can produce a fluent, confident explanation of the code and still have understood a fraction of the behavior that matters. Faithfulness is a property of the whole behavior of a system, and that is the standard any serious verification has to meet.

This question is older than AI

Here is what struck me most in that conversation: the faithfulness question did not arrive with AI. It has existed for as long as the same COBOL could be compiled by more than one compiler.

Today there are two open-source COBOL compilers under active development, built on genuinely different architectures, one translating COBOL through C, the other a native front-end inside GCC itself. Their correctness is established not by assumption but by discipline: thousands of standardized test programs, run and compared against reference behavior, with every genuine divergence treated as a bug to be reported and fixed. Decades of that discipline are why an open-source compiler can be trusted with code it did not originate.

AI-assisted conversion faces the same demand, proving the new behaves like the old  but so far with far less of that discipline around it. Generated Java that compiles and runs cleanly is routinely accepted on a fraction of the evidence we would require before trusting a compiler. That asymmetry, more than any single tool’s capability, is what I find worth examining.

The evidence we do have is motivated

Occasionally, reality offers a way to check. The US Centers for Medicare & Medicaid Services ran its Medicare “Pricer” programs, the logic that calculates what Medicare pays for each claim in COBOL for decades, completing a conversion to Java in January 2022. Because CMS publishes this material, the historical COBOL sits in the public PC Pricer archive: real programs, from a few thousand lines to nearly twenty thousand, with a known modernization history. A rare public before-and-after.

Earlier this year, Swimm, a company selling a deterministic code-analysis platform, published tests running a general-purpose AI assistant against exactly these programs. What they reported reads like a catalogue of understanding gaps: business rules that never surfaced on the larger programs, a dropped condition, an incorrect historical dollar figure, different answers on repeated runs precisely the kind of reading failures that would become silent omissions in a rewrite. It is worth reading, and worth reading skeptically: a vendor benchmarking a competing approach against its own product, and scoring itself perfectly, is publishing motivated evidence, even where the individual observations are real. That is the honest state of the public record. AI vendors publish demonstrations where AI shines; their competitors publish demonstrations where it stumbles. Both are informative. Neither is neutral.

So which is it?

I am not going to resolve that here, and I do not think I should not yet, and not alone.

The questions I find worth answering are narrower and harder than the loud ones. When an AI reads a real program, how much of its actual behavior does it capture and when it converts one, what does it preserve and what does it silently drop? Does a model built specifically for the mainframe reach meaningfully further than a general-purpose one? And what would it take to bring conversion under the same kind of evidence discipline that compilers have been held to for decades so that “it runs” stops standing in for “it is the same”?

Those are the questions my mentorship whitepaper will take up, using code that is public, tooling that is open, and no product to sell at the end of it.

An invitation

This is where I need the community, because experience answers this better than analysis. If you have been through a modernization effort with AI in the loop or without. I would like to hear what you saw. Where did the tools help more than you expected? Where did a conversion that “passed” quietly lose something that mattered?

To make that easier, I am working with the Open Mainframe Project on a short practitioner survey about where AI was used, how the new code was checked, and what surprised teams afterward — shared through the Linux Foundation’s network. Fill out the survey here. 

I am at the beginning of this, not the end. If you have a perspective especially one that complicates the easy version of the story, I would be grateful to learn from it.

This post is part of my Open Mainframe Project Summer 2026 mentorship, exploring the role of AI in mainframe application modernization. The full whitepaper will follow.

Stay tuned for more mentee blogs as our Summer Mentorship Program continues!

Share