Mainframe Exit Is the Wrong Question in the Age of GenAI

Generative AI is reshaping mainframe modernization, but it doesn’t eliminate the complexity of migration. For insurance carriers, success depends on understanding business logic, regulatory requirements, operational dependencies, and the right modernization path for each workload.

Generative AI has put mainframe strategy back on the executive agenda. For insurance carriers running policy administration, claims, billing, and actuarial workloads on IBM Z, the pitch is seductive: AI can finally read the COBOL, document the business rules, and convert the code—so why not finally get off the mainframe?

The Gartner April 2026 research, “Too Big to Fail: Why Mainframe Exit Projects Are Likely to Fail in the Age of Generative AI,” offers a sober counterpoint. Gartner projects that more than 70% of mainframe exit projects initiated in 2026 will fail to produce the intended benefits due to an overestimation of generative AI tooling capabilities.

The caution is warranted, but we believe “don’t leave the mainframe” is the wrong lesson to take away. The better one is this: Generative AI doesn’t make mainframe exit easy—it makes poor strategy easier to execute, faster.

To understand why, it helps to be precise about what generative AI does well—and what it doesn’t.

 The New Enthusiasm and Its Blind Spot

The enthusiasm among CIOs and CTOs for generative AI is justified: large language models are demonstrably useful at summarizing legacy code, extracting business rules, and accelerating parts of the modernization lifecycle that used to require months of manual archaeology. The blind spot is that code conversion is only one piece of what makes a mainframe environment hard to leave. The Gartner report identifies three separate domains where generative AI has impact—code understanding, code conversion/completion, and IT system operations (e.g., automation, subsystem administration, etc.)—and notes that, when it comes to GenAI tooling, the maturity and effectiveness vary across these three areas.

Reading and explaining fifty-year-old COBOL is a different problem than safely reproducing its behavior, including the edge cases, undocumented workarounds, and regulatory logic embedded in it over decades of change requests. For an insurance carrier, that embedded logic is rarely trivial. Policy rating engines, underwriting rules, claims adjudication logic, and statutory reporting calculations often encode actuarial and regulatory decisions made by people who have since retired.

AI can help surface that logic. It can’t certify that it’s captured all of it—and in a regulated industry, an incomplete conversion isn’t a bug to fix in the next sprint. It’s a compliance and policyholder-trust event.

Why “Exit” Is the Wrong Frame for Insurance

The language of “mainframe exit” presupposes the answer before the analysis has been done. It frames the mainframe itself as the problem, when for most carriers the platform isn’t what’s failing—it’s unclear ownership of the target state, incomplete understanding of embedded business logic, and a governance vacuum that lets a vendor’s tooling roadmap substitute for an actual strategy.

A more useful set of questions for an insurance executive to ask of any given workload includes:

• Which workloads create differentiated business value—proprietary rating models, claims logic, or customer data—versus those that are simply expensive to run?
• Which are constrained by regulatory or statutory requirements that make platform change a compliance decision, not just a technical one?
• Which depend on institutional knowledge held by a shrinking pool of COBOL, CICS, JCL, DB2, or IMS specialists?
• Which require the resiliency, transactional integrity, and “five nines” availability the mainframe delivers out of the box—and which would need that same rigor rebuilt, at cost, on another platform?
• Which are stable, low-change workloads best left alone, and which need the elasticity and pace of change that cloud-native architectures provide?

None of these questions are answered by asking, “What tool can convert our COBOL?” They’re answered by evaluating the estate workload by workload—which is precisely the discipline that gets skipped when “exit” is treated as the strategy rather than a possible outcome for some subset of applications.

What Actually Causes Mainframe Modernization to Fail

The Gartner research attributes much of this failure risk to an overestimation of generative AI tooling capabilities. We agree, but it’s only part of the picture. In Ensono’s experience with insurance and financial services clients, failure is rarely a single-cause event. It’s usually a combination of:

• A lack of organizational readiness and unrealistic expectations about timeline or cost.
• Business and IT misalignment on what modernization is meant to achieve.
• Regulatory and statutory constraints specific to insurance, reinsurance, and multi-state or multi-jurisdiction compliance.
• Talent gaps around COBOL, Assembler, JCL, CICS, DB2, and IMS, compounded by an aging workforce.
• Incomplete knowledge of embedded business logic going into the project.
• An underestimation of the operational, security, data, and resiliency requirements the mainframe was quietly satisfying all along.

This is consistent with the Gartner findings, which estimate that by 2030, 75% of vendors operating in the “mainframe exit” market will either pivot their business models or cease to exist.

A market built primarily on the promise of tool-led conversion becomes vulnerable the moment enterprises discover that tooling was never the binding constraint.

The Better Question: Workload Intelligence

Ensono’s position is that mainframe modernization shouldn’t be framed as a binary choice between “stay” and “leave.” It should be treated as a workload-by-workload decision discipline, grounded in business value, regulatory requirement, operational resilience, cost, data gravity, and modernization readiness.

For a large mainframe environment (25,000+ MIPS)—the profile typical of national and multi-line insurance carriers—this generally means pursuing what Gartner terms a “platform-smart” strategy: optimizing and modernizing in-place, maintaining a direct relationship with IBM, and reserving migration for the specific workloads where the business case is clear rather than assumed.

The calculus shifts for mid-sized and smaller carriers, but the discipline is the same—the environment size changes which strategic paths are viable, not whether an intelligence-led approach is warranted.

What This Means for Insurance Executives

For carriers, the stakes of getting this wrong aren’t merely budgetary. Policy administration, claims processing, and billing systems are the operational core of the business—the systems of record for premium, coverage, and claims obligations, often under active regulatory audit. A migration that underestimates embedded logic doesn’t just risk schedule slippage; it risks miscalculated premiums, mishandled claims, or reporting failures with regulatory consequences.

The executives best positioned to benefit from generative AI in this environment aren’t the ones asking their teams to find a tool that will “get them off the mainframe.” They’re the ones who know enough about what’s running on it to make that call responsibly.

This is the first article in a multi-part series exploring how insurance technology leaders should think about their mainframe strategy in the age of generative AI.

Frequently Asked Questions

Why do mainframe modernization initiatives fail?

Mainframe modernization initiatives can struggle when organizations underestimate application complexity, embedded business logic, regulatory requirements, operational dependencies, or the level of organizational change required to support transformation.

Can generative AI help modernize mainframe applications?

Yes. Generative AI can help teams analyze legacy code, document business rules, accelerate knowledge transfer, and support modernization planning. However, organizations still need to validate business outcomes, operational requirements, and application behavior.

Should insurance carriers migrate all mainframe workloads?

Not necessarily. Some workloads may benefit from migration, while others may be better suited for modernization in-place. The right approach depends on factors such as business value, resiliency requirements, regulatory obligations, and modernization objectives.

How should insurance executives approach mainframe modernization?

Insurance executives should evaluate applications and workloads based on business value, regulatory considerations, operational requirements, and long-term modernization goals. The focus should be on selecting the right modernization path for each workload rather than assuming a single approach applies to the entire environment.

Gartner, Too Big to Fail: Why Mainframe Exit Projects Are Likely to Fail in the Age of Generative AI, By Dennis Smith, Alessandro Galimberti, Tobi Bet, 8 April 2026. GARTNER is a trademark of Gartner, Inc. and/or its affiliates.