Mainframe and COBOL Modernization with Agentic AI: What’s Actually Possible in 2026

COBOL still runs the plumbing of the global economy. The language supports more than 40 percent of online banking systems, 80 percent of in-person credit card transactions, and 95 percent of ATM transactions, according to IBM. It has also become the subject of a noisy, overconfident sales pitch in 2026: a growing menu of vendors promising that agentic AI can finally solve mainframe modernization, sometimes with the implication that it can do so on its own.

Gartner’s own research says otherwise. The firm warned in June that more than 70 percent of mainframe migrations started this year will fail, driven largely by technology leaders overestimating what generative AI can actually do for transforming legacy implementations. The gap between what’s being pitched and what’s actually possible is the real story in 2026, and it’s worth being precise about where that gap sits.

Gartner VP Analyst Matt Brasier put the underlying issue bluntly: legacy system modernization remains an unsolved business problem, not an unsolved technical problem. The questions CIOs actually face have never been about whether AI can read old code. They’re about whether the business case holds up: how much it will cost, how much organizational change it will require, and whether the outcome justifies it.

That framing matters because it’s easy to mistake faster code translation for a solved modernization problem. It isn’t. The systems in question sit underneath transaction volumes and regulatory obligations large enough that a failed migration is not a minor setback, which is exactly why Gartner’s failure-rate warning carries weight.

The clearest example of overreach arrived in February 2026, when an AI lab claimed its coding tool could handle COBOL modernization for systems of any size, a claim significant enough to send the mainframe market’s leading vendor’s stock down and prompt a wave of skepticism from people who actually run these migrations. Mitch Ashley, VP and practice lead of software lifecycle engineering at The Futurum Group, called the idea that a single AI tool would “do all the modernization for COBOL” an unrealistic claim on its face, given how much enterprise trust and track record still separates a capable model from a dependable migration partner.

Brasier’s read on the technology itself is more measured than either the hype or the panic that followed it. Machine learning has already been used for years to help document what COBOL applications do and to build test cases around them, he noted. Generative and agentic AI extend that work, but the description he used was direct: “It’s just another automation tool at the end of the day.” He also flagged a structural conflict of interest worth taking seriously: vendor modernization tools are generally built to move an enterprise onto that vendor’s own stack, whether that’s a Java-based platform or a cloud-native serverless one, which may or may not be where the organization actually wants to end up.

Set the hype aside and the real 2026 track record is still substantial, just more specific than the pitch decks suggest.

Morgan Stanley has modernized more than 17 million lines of COBOL, Natural, and PERL code using an in-house generative AI platform, saving developers more than a million hours of manual coding in the process. The firm’s global head of technology strategy, architecture, and modernization, Trevor Brosnan, described coding tasks that used to take a week now taking half a day, with the platform reverse-engineering old code into a clear design before anything gets migrated into updated architecture, all under full human oversight.

Toyota Motor North America used AWS’s agentic modernization tooling to convert more than 40 million lines of COBOL to Java. McKinsey’s research documents a comparable case at a bank modernizing 20,000 lines of legacy code: a project originally estimated at 700 to 800 hours saw that estimate cut by 40 percent once an orchestrated set of gen AI agents took on the work, with the relationship-mapping step alone dropping from 30 to 40 hours down to about five.

Ascendion’s own delivery record follows the same pattern at a different institution. For a digital-first banking pioneer, AAVA™ reverse-engineered more than 900,000 lines of 1980s-era banking code in three weeks, landing the modernization program at roughly a quarter of its $36 million projected cost and in half the time a traditional approach would have taken.

The common thread across every one of these results is the same: none of them are a single model translating code line by line. Each one starts with reverse engineering to understand what the system is actually doing before anything gets rebuilt.

Asa Kalavade, who leads AWS’s Transform initiative, framed successful mainframe modernization as depending on both reverse engineering and forward engineering together, not a single migration event. “It’s going to be a journey,” Kalavade said, one where some workloads stay on the mainframe and others move to the cloud, often for years at a time.

That matches the failure mode worth avoiding on the other side: translating legacy code directly into a modern language without first understanding what it does just relocates the technical debt into a newer-looking system, rather than resolving it. Reverse engineering first, understanding the business logic before deciding what to rebuild, redesign, or discard, is what separates the production results above from a modernization program that produces a lot of converted code and very little business value.

It’s also why some enterprises are choosing to keep the mainframe rather than exit it. Steven Dickens, CEO of HyperFRAME Research, described a shift where the platform itself is “being architected to lead in the era of AI” rather than being replaced by it, with AI increasingly brought directly to mainframe data instead of forcing a full rip-and-replace. “I see AI as a tailwind for the mainframe, not the opposite,” he wrote. Whether the right outcome is migration, modernization in place, or some hybrid of both is a decision the technology itself doesn’t make. It still has to come from the business case.

The step change in 2026 isn’t that AI can read COBOL. Machine learning tools have done that for years. What’s new is the ability to orchestrate many specialized agents across an entire modernization workflow rather than pointing one model at a code translation task: agents that map data and dependencies, agents that handle security design and compliance analysis, and agents that test and validate each other’s output, with defined escalation paths back to a human when something falls outside what the agents can resolve on their own. That orchestration, not any single agent’s coding ability, is what accounts for the gap between the production results above and the failure rate Gartner is warning about.

A few practical conclusions follow from where the evidence actually sits. Treat any vendor pitch promising full automation with the same skepticism Gartner’s own analysts apply, and ask the same questions Brasier poses: what will this actually cost, how much organizational change does it require, and is the outcome worth it. Understand up front which stack a vendor’s tooling defaults you toward, since that destination may not be the one your organization has in mind. Insist on a reverse-engineering-first methodology rather than a direct code translation pitch, since that distinction is what separates the production wins above from the migrations Gartner expects to fail. And plan for a hybrid outcome rather than a single cutover event: some workloads modernizing off the mainframe, others staying on it with AI applied directly to the data and processes already running there.