70% of Mainframe Exits Fail in 2026. The 30% Playbook.

TL;DR

Gartner now attaches a number to the fear every bank CTO already carried: most GenAI-driven mainframe exits started in 2026 will fail. The institutions that avoid the headline modernize one business process at a time while the core keeps running. Coexistence works as a durable operating model, one that lets a regulated business move at its own pace and reverse when reality bites. Used where it belongs, in discovery and dependency mapping, AI accelerates the work instead of gambling the estate on a guess. The safest place to begin is the smallest: prove one process in production before anything touches the core.

Somewhere in most banks and insurers, a CIO has signed off on a plan to exit the mainframe, or is being pushed toward one. The pitch is confident: point generative AI at the legacy code and leave the old system behind. In June 2026, Gartner put a hard number on how that ends. The safer route is incremental mainframe modernization, moving one business process at a time while the core keeps running. What follows is why the big exits fail, and how to modernize without putting the business at risk.

Why most 2026 mainframe exits will fail

Every mainframe-exit decision now doubles as a personal-risk decision. The CIO who signs the approval owns the result, and the result is no longer a matter of opinion. In June 2026, Gartner attached a number to it: more than 70% of mainframe-exit projects initiated in 2026 will fail to produce their intended benefits, and 75% of exit vendors will pivot or cease operations by 2030 (Gartner press release, June 18, 2026). The Register called AI-powered mainframe exits "a bubble set to pop" (The Register, April 15, 2026).

For a bank or insurer, that figure reads differently than for a technology startup. Your core clears transactions every night without missing one, while the board asks why you still run a mainframe and where the AI story is. The role carries no reward for moving fast and a lasting penalty for a failed cutover.

So why do the exits keep failing? The failure is not new, and it is not rare. Bank CTOs still remember TSB in 2018, and the pattern repeats today: in February 2026, a core-system migration at Bancolombia locked more than 20 million customers out for days, with its backups failing alongside the main system (The Rio Times).

The pitch is easy to believe: point generative AI at decades of COBOL and walk away from the hardware. Production is where that confidence meets the estate. Gartner's Alessandro Galimberti, the VP Analyst behind the 70% call, names the gap plainly: "There is a widening gap between the marketing promise of GenAI and its real-world ability to transform and migrate complex legacy code" (Gartner, June 18, 2026). Around 80% of core-banking migrations fail, "usually due to incomplete or incorrect data," according to Objectway (The Wealth Mosaic). The estate is the reason projects fail, and the estate is exactly what an incremental approach respects.

What the 30% do differently: one process at a time

If a full exit fails seven times out of ten, the answer is not to freeze. The teams that succeed change the unit of work. They modernize one business process at a time, while the rest of the estate keeps running untouched.

Incremental mainframe modernization means modernizing the mainframe one business process at a time instead of in a single cutover. You pick a defined process, expose and rebuild it on a modern target, and run it alongside the legacy system. The core keeps operating throughout, and each process ships as its own contained piece of work.

Scope is what turns the risk down. A big-bang cutover puts the whole institution on the line on one date. A single process carries a boundary you can see, test, and reverse. When something breaks, the blast radius is one process, not the bank.

The market has already moved this way. 80% of organizations shifted their mainframe modernization strategy in the past year, and phased projects report between 288% and 362% ROI depending on the path taken, whether they modernize on the mainframe, integrate with cloud, or move workloads to other platforms (Kyndryl 2025 State of Mainframe Modernization).

The logic is the whole point. As OpenLegacy frames it, one business process done right is worth more than a full estate rewritten on a guess. Each process you modernize becomes a result in production, not a bet still waiting to pay off.

Coexistence as a durable operating model

Most modernization vendors talk about coexistence as a temporary bridge, a holding pattern until you finish migrating onto their platform. The framing serves the vendor, whose economics depend on you finishing on their cloud.

Treated as a durable operating model, coexistence becomes far more useful. The mainframe and the modern targets run in parallel for as long as the business needs, and each modernized process talks to the systems still on the mainframe through generated integration bridges and API facades. You modernize at the pace the institution can absorb, rather than the pace a migration contract demands.

Reversibility follows from the same design. When old and new run side by side, the legacy system stays as the fallback by default. If a modernized process misbehaves, traffic stays on the mainframe while your team fixes it. The safety net lives in the architecture rather than in a runbook you hope holds under pressure. Bancolombia's outage traced back to backups that failed at the worst moment, and parallel operation removes that single point of failure.

The approach also stays destination-agnostic. A modernized process can land on AWS, Azure, Google, Java, .NET, Salesforce, Pega, or an in-house framework, because the model owns the handoff rather than the endpoint. AWS's Omri Kessel described the same incremental logic when OpenLegacy embedded into AWS Transform, letting customers modernize "incrementally, in months, instead of betting the business on a big-bang cutover" (PR Newswire, June 2026).

So coexistence earns its place as the strategy itself: the way a regulated institution modernizes without putting the core at risk on any single date.

Where AI actually belongs in the work

None of this is an argument against AI. The 70% failure rate comes from asking AI to do the one thing it does worst, not from using AI at all. Nearly 90% of organizations have deployed or plan to implement generative AI on the mainframe (Kyndryl 2025), so the question is no longer whether to use it, but where.

AI earns its place where ambiguity and scale are the real problem. Reading millions of lines of undocumented COBOL and mapping dependencies across a tangled estate is work no human team can do at speed. AI does it well, surfacing the business rules buried in decades of change. OpenLegacy applies AI exactly there, in discovery, to build a truthful map of what the system actually does.

Breaking the exit into one process at a time helps the AI too. A single process is a bounded problem, so the model reasons over a small, well-defined context instead of the whole estate at once, and that is where GenAI becomes more reliable. The same move that lowers the business risk also raises the quality of the automation.

Deterministic engineering takes over where consistency and auditability matter. Turning that map into working code or a packaged platform is no place for a model to improvise, because a regulated core cannot ship rules that "usually" match the original. Rule-based generation produces the same output every time, which is what an auditor and a risk committee expect.

Gartner's Galimberti points this way, noting GenAI is often more effective at enabling modernization than at lifting an estate off the platform in a single pass (Gartner, June 2026). Used like this, AI accelerates incremental modernization instead of gambling on it. You still move toward your target, faster, with a map you can trust and code you can defend.

How to prove it without betting the core

The hardest part is the first move, because every option feels irreversible. It does not have to be. You pick one process and modernize that, not the whole mainframe. What matters is the scope: one process with a clear boundary, proven in production before anything else is touched.

How to choose that first process

Not every process makes a good first candidate. The useful filter is business value weighed against complexity. A process that is high in value and reasonable in complexity gives you a result the board can feel, without taking on the hardest corner of the estate first. A process can even be an urgent one, as long as its boundary is clear.

OpenLegacy weighs several factors together: business value (revenue, cost, customer and risk impact), complexity (programs, interfaces, data models), estimated delivery effort, upstream and downstream dependencies, regulatory and security exposure, and transaction volume.

The candidates usually sit among the processes every institution already runs: payments, account opening, or KYC in banking; claims intake, underwriting, or a new-business quote in insurance; client onboarding or trade capture in wealth and capital markets. Take one of these, read it against value and complexity, and you can tell fairly quickly whether it is the right place to begin.

A strong first candidate often does double duty: modernizing it frees the data and logic an AI use case has been waiting for, putting a business process and real AI value into production together.

Modernizing a single process follows a repeatable path:

• Scope it. Map the business flow and the code beneath it, and define what the first version has to do.
• Prove it. Expose the process through clean APIs and test the new flow against the behavior of the original.
• Move it to production. Run old and new in safe coexistence until the modernized process earns trust, then go live without a cutover event.

By the end, you hold a modernized process in production, its data and logic now open to an AI use case, and a repeatable pattern for the next one, with no high-stakes cutover date on the calendar.

So the first step stays small on purpose. One process, proven in production, becomes the evidence the board needs to fund the next wave.

Modernize the mainframe without betting the business

The choice the board keeps framing, keep paying to run the mainframe or gamble the core on a cutover, is a false one. The 30% who succeed in 2026 will take neither path. They modernize one business process at a time and keep the mainframe running as the safety net, letting each result fund the next.

For a CIO or CTO, that turns an exposed decision into a controlled program. You show the board a modernized process running in production, a coexistence architecture that reverses cleanly if a problem appears, and a repeatable path to the next process, with your name on a plan that works instead of a cutover that might not.

The move is small and it is yours to make: pick one process, read it against value and complexity, prove it in production, and let the evidence make the case for the rest.

FAQ

Is incremental mainframe modernization slower than a big-bang migration?

On paper a big-bang looks faster, yet Gartner expects most 2026 exits to fail, which resets the clock to zero. Modernizing one process at a time delivers a working result in production early and compounds from there, so the incremental path usually reaches real value sooner and with far less risk.

Is coexistence only a way to delay an eventual mainframe exit?

No. Coexistence works as a durable operating model rather than a waiting room. Old and new run in parallel for as long as the business benefits, and each modernized process can move to any target you choose. You exit workloads at the pace that suits the institution, or hold the balance for as long as it serves you.

How long does it take to modernize one mainframe process?

Timelines vary with the complexity of the process, its dependencies, and the target platform. The pattern stays the same: scope the flow, prove it against the original behavior, then run it in coexistence before going live. Because the scope is one process, you reach a production result in a defined, contained window, and OpenLegacy structures it as a repeatable path so the next one moves faster.

What makes 2026 different for the mainframe-exit decision?

Two forces collided. Boards pushed GenAI-led exits hard, and Gartner then predicted more than 70% of those 2026 projects will fail. The credibility correction is live now, which makes an incremental, coexistence-based approach the defensible position for any CIO signing off this year.

Who owns the risk if a modernization vendor fails mid-project?

You do, which is why continuity matters as much as capability. Coexistence limits the exposure, because the mainframe keeps running as the fallback and no workload is stranded. OpenLegacy also runs inside AWS Transform for Modernization and holds the AWS Mainframe Modernization Competency, so the platform relationship backs its support and longevity.

Can incremental modernization reduce mainframe run cost?

Yes, gradually. Each process you modernize or move can trim MIPS consumption and the maintenance load around it, and you capture those savings process by process rather than waiting years for one migration to land. The reductions accrue while the core stays fully operational.