Why AI COBOL-to-Java Migration Passes Tests and Still Corrupts Production Databases

The Mechanism Behind the Silent Failure

COBOL programs rarely exist as self-contained files. They pull in copybooks: shared definition libraries that can run thousands of lines and live far from the module being translated. Inside those copybooks sit constructs like REDEFINES, which allows the same block of memory to hold different data types depending on conditions set elsewhere in the program.

An AI agent reading a wire transfer module may encounter a variable like TRN-LIMIT and interpret it as a simple numeric field. In the mainframe environment, that variable holds a packed decimal, governed by a REDEFINES clause in a copybook the model either did not fully process or processed incorrectly. The Java output treats it as a standard integer. The binary data written to the database column is wrong—not obviously wrong, but structurally wrong in a way that passes tests and corrupts records.

That is not a translation error at the margins. That is the translation failing at its core purpose.

Why Models Miss What Matters

Researchers have a name for part of this problem. Transformer models tend to lose accuracy on information buried in the middle of a long context window—a pattern widely described as “lost in the middle.” A single COBOL program with its full copybook dependencies can present exactly this structure: the critical definition sits neither at the top nor the bottom, where the model’s attention is strongest.

The model does not know what it missed. It produces code that looks correct, narrates what the program appears to do, and offers no signal that the narration is wrong. In a modernization project, a confidently wrong answer is worse than an honest failure, because it passes review.

Academic work published in 2026 reinforces this concern. Research framed around agentic legacy translation argues that line-by-line conversion can compile and run while still breaking edge-case handling, validation logic, or hidden constraints. Separate work on COBOL-specific challenges notes that general-purpose language models struggle with COBOL as a low-resource language with its own logic patterns—patterns that do not map cleanly onto the training distributions these models know best.

The IBM Reaction Was Telling

When Anthropic announced in February 2026 that Claude Code could automate much of the analysis behind COBOL modernization—mapping dependencies, documenting workflows, identifying risks—IBM’s stock dropped sharply. The market read it as a threat to IBM’s mainframe services business.

IBM’s response was pointed. Rob Thomas, the company’s senior vice president for software, argued publicly that translating COBOL and modernizing a platform are not the same job, and that translation captures almost none of the actual complexity. He pointed to the full IBM Z stack—z/OS, CICS, IMS, Db2, RACF, MQ—and the decades of hardware-software integration that surround the code itself.

You do not have to accept IBM’s framing uncritically to see the validity of the underlying point. A mainframe application is rarely just a file of COBOL waiting to become Java. It is batch schedules, database contracts, job control language, character encodings, access control rules, and business logic that may have survived three generations of management without ever being written down in one place.

The Scale of What Is at Stake

The installed base makes this problem consequential rather than academic. Industry surveys have estimated hundreds of billions of lines of COBOL in daily production use, with the majority of organizations describing it as strategically important to their operations. Government systems are no different: the IRS’s core individual taxpayer account database dates to the late 1960s, and modernization programs at that scale are measured in billions of dollars and decades of effort.

The people who built these systems are retiring. Documentation is thin. The code still moves money, taxes, and insurance claims. If an AI tool can read and map a codebase faster than a human analyst, every bank and government agency has a rational reason to test it. The pressure to act is real.

But testing a tool is not the same as trusting it to own the outcome.

What the Market Is Actually Choosing Between

Major cloud providers have moved quickly. AWS, Google Cloud, and Kyndryl have all announced or expanded mainframe modernization offerings that incorporate generative AI. Gartner, however, projected in mid-2026 that more than 70% of mainframe exit projects initiated that year would fail to produce their intended benefits, citing overestimation of generative AI’s capabilities alongside the older, persistent causes: unclear ownership, undocumented logic, and scope creep.

The market is not choosing between AI and no AI. That choice has already been made. The real choice is narrower and more consequential:

• Use the AI agent as a fast analyst inside a verified, human-supervised process with explicit copybook resolution, semantic testing, and production-equivalent data validation.
• Or treat the agent as a replacement for the map, the tests, and the people who understand why the old system behaves the way it does.

The Practical Takeaway

The failure mode described here—clean compilation, passing tests, corrupted production data—is not a reason to avoid AI-assisted modernization. It is a reason to be precise about what AI-assisted modernization actually means.

Any migration process that does not explicitly account for copybook dependencies, REDEFINES clauses, packed decimal handling, and the full runtime environment of the source system is incomplete, regardless of how capable the underlying model is. The AI accelerates the readable parts of the work. It does not automatically surface the parts that were never written down.

TRN-LIMIT is not an obscure edge case. It is the kind of variable that exists in every large COBOL system. Finding it—and proving the translation handles it correctly—is the work. Everything before that is preparation.