Why Japanese Enterprises Keep Failing at Mainframe Retirement

The number no one is talking about

Seventy percent. That is the figure Gartner floated in June 2026 for mainframe retirement projects launched that year that would fail to deliver their intended benefits. It is not a forecast for five years out. It is not a estimate for ambitious greenfield migrations. It is about projects already underway, projects whose executives signed off on budgets, set timelines, and staked reputations on the assumption that the hard part—the code migration—was now solvable with a new set of tools.

The tool in question is generative AI. The assumption was that AI could read decades-old COBOL and JCL, understand the business logic buried inside, and rewrite it into modern languages with enough fidelity that the real work would be validation, not reconstruction. On paper, this was the most plausible path yet out of the legacy trap. In practice, it appears to have made things worse by convincing leaders the trap had already opened.

What Gartner actually said

Alessandro Galinberti, Gartner’s vice president and analyst, did not frame this as a generative AI failure. He framed it as a confidence gap. In his assessment, the market narrative around AI’s ability to translate and migrate complex legacy code is disconnected from reality. Vendors, he said, are embedding AI into their migration offerings not because the evidence is strong, but because investor pressure demands it. The result is a product cycle moving faster than the proof.

That pattern is familiar across the enterprise software industry. But it hits differently when the system being retired runs payroll, supply chain, or core banking for a company that has survived thirty years on it. A failed web app migration is expensive. A failed mainframe migration is existential. And the pool of people who understand what the mainframe actually does is shrinking faster than the code can be translated.

Hitachi closes the door

Hitachi’s announcement this spring was a structural shock. The company confirmed it would end sales of VOS3, its domestic mainframe operating system, in November 2027 and terminate all maintenance by December 2034. Fujitsu and Japan IBM launched a joint effort aimed squarely at COBOL asset modernization around the same time. For decades, Japanese enterprises had a path: stay on domestic mainframes, rely on vendors who would keep them running, and defer the hard decision.

That path is now closed. The remaining exit ramps are narrow, and they all lead through the same bottleneck.

The consultant vacuum

Hiroaki Kato of Japan Tata Consultancy Services described the bottleneck in blunt terms. His firm was working on an SAP ECC 6.0 migration when the consulting partner overseeing the project had its development team pulled away for another engagement. The client then approached fifteen domestic vendors capable of taking over. All fifteen declined. The project was worth hundreds of millions of yen.

This is not a recruitment problem. It is a capacity problem. The consultants who can navigate SAP-to-cloud migrations, mainframe-to-distributed rewrites, and the business-process reengineering that accompanies them are few, and the market demand across every major enterprise is outstripping supply. Kato noted that the rejection of even a multi-million-yen engagement signaled how deep the shortage runs. When the people who usually absorb risk and uncertainty in these projects are nowhere to be found, the risk does not disappear. It moves onto the balance sheet of the company that hired them.

The real missing skill

Here is the insight that cuts against the prevailing IT headline: the shortage is not about COBOL programmers. Eimei Goto of Hitachi, who leads the company’s Modernization Center of Excellence, stated this directly. The problem, she said, is that fewer people understand why the current system exists in its current form. Specifications documents capture what the code does. They rarely capture why it was designed that way, what trade-offs were accepted, which business rules are flexible and which are non-negotiable, and which dependencies outside the application are the real constraints.

This distinction matters because generative AI is excellent at pattern matching within code, and terrible at reasoning about intent that lives in nobody’s documentation. An AI can translate a COBOL program into Java. It cannot tell you whether that program’s quirky rounding behavior was a bug or a carefully negotiated compliance requirement from 1998. It cannot interview a retired operations manager and recover the institutional knowledge that explains why the legacy system handles month-end processing in the order it does.

The planning step everyone skips

Kato’s prescription was straightforward and widely ignored in practice: spend disproportionate time on project conception and requirements definition before any code changes hands. Build a realistic timeline. Map the staffing model. Produce an accurate cost estimate. Secure the budget on those terms. If the company has internal staff with core-system modernization experience, assemble them into a conceptual-planning unit that drafts the request for proposal and evaluates vendors on capability, not marketing.

This is not a new idea. It is simply the one that generative AI made people feel they could skip. The assumption was that AI would perform the heavy lifting of analysis and translation, leaving humans to review output. The 70 percent failure rate suggests the opposite: without rigorous upfront planning, AI-generated migrations produce systems that look correct and fail under real load, or worse, behave correctly until an edge case surfaces months after go-live.

The devil phrase

Yoshihiko Murawaki of SCSK wrote about a pattern he called the “existing-function guarantee”—a phrase that became, in his words, demonic. It appears in RFPs and contract negotiations when clients ask vendors to assure them that every existing feature will work identically in the new system. The problem is structural. After ten or more years, even the original builders do not remember why certain functions exist. Demanding a guarantee of identical behavior is demanding certainty about a system whose logic is partially undocumented and partially held by people who have retired.

Murawaki’s observation matters because it explains a common failure mode in modernization projects: the new system passes acceptance tests but fails in production because something subtle and untested depended on legacy behavior that nobody documented. The closer the new system mirrors the old, the more likely it is to preserve bugs alongside features. The looser the constraint, the higher the risk of functional regression. There is no clean path through this, only better planning.

Where Hitachi is actually using AI

Hitachi’s own adoption pattern offers a clue about where generative AI fits without overpromising. The company is using it for present-new comparison testing—feeding output from both old and new systems into an AI model and asking it to surface discrepancies and possible causes. This is a narrowing of scope from the ambitious claim that AI can replace human analysis of legacy code. It is also a more honest application: the AI is acting as a force multiplier for human reviewers, not a substitute for them.

Even this narrowed use case acknowledges a boundary. Hitachi’s materials note that certain judgment calls remain firmly in human territory. Discrepancies that look like bugs may be intentional design differences. Differences that look safe may expose compliance gaps. The AI surfaces the questions. Humans answer them.

What this means globally

Japanese enterprises are not unique in struggling with legacy modernization. But Japan’s combination of domestic mainframe dependence, a rapidly aging technical workforce, and the current consultant shortage makes the data especially sharp. The 70 percent failure rate is a warning signal for any market where leaders have concluded that generative AI solves the hard part of migration.

The hard part was never the code. It was the context. And context does not transfer through a prompt.

The remaining play

With Hitachi exiting domestic mainframe hardware and Fujitsu-Japan IBM coordinating on COBOL modernization, the window for orderly migration is closing. Companies that enter the next six months without an internal team capable of rigorous requirements definition, realistic cost modeling, and vendor evaluation will be negotiating from a position of acute scarcity. The consultants they need will be unavailable or priced beyond budget. The AI tools will produce output that looks sufficient and fails under scrutiny.

The companies that survive this period will be the ones that treated the planning phase as the project, not the prelude. They will have staff who understand not just what their systems do, but why. They will use generative AI as an analytical aid, not a strategy. And they will enter contracts with vendors who can demonstrate migration competence, not just AI-enabled marketing.

The alternative is a second wave of failures, this time blamed on the tools rather than the approach.

The timeline that matters

Hitachi’s VOS3 maintenance end date is December 2034. SAP ECC 6.0 support ends in 2027 for extended-maintenance scenarios and earlier for standard support. Every quarter of delay reduces the set of viable vendors, increases the cost of migration, and narrows the window for testing under realistic conditions. The companies that begin substantive planning now have a structural advantage. The companies waiting for AI to make the work easier are waiting for something that, according to the data so far, does not exist.

The 70 percent figure is a forecast, not a verdict. But forecasts based on projects already in motion are as close to a verdict as enterprise IT gets.