The mainframe will outlive your AI strategy. We have not yet walked into a financial services or insurance engagement where this was not true, and we have stopped pretending otherwise on the first slide. The legacy system is not the problem to be solved. It is the constraint to be designed around.
This shows up most often as a rewrite proposal. Some vendor or internal champion arrives with a deck that says the mainframe goes away in eighteen months and Python and an LLM wrapper take over. We have seen four of these proposals in the last two years. Zero of them have shipped. The mainframe is still there in all four cases, and in two of them the team that proposed the rewrite is not.
Why mainframe modernisation as rewrite keeps failing
The mainframe is not slow. It is not buggy. In every engagement we have run, the COBOL or PL/I underneath has fewer production defects per million transactions than whatever Java or Python service is calling it. What is slow is the change cycle around it. Deploys are quarterly, the team that maintains it is half the size it was five years ago, and the documentation is a Word file from 2014.
The rewrite proposal misreads this. It assumes the problem is the technology, and proposes to replace the technology. What is actually broken is the operating model around the technology. A rewrite does not fix the operating model. It just adds a new system that has to be operated, while the old one is still load-bearing for the next four years of the migration.
The other thing the rewrite proposal misreads is how much business logic lives in COBOL that nobody can fully describe. We have read postmortems from at least two banks where the rewrite went live, missed a calculation that the original code handled correctly, and produced reconciliation breaks for six months until the team gave up and routed traffic back to the mainframe.
What mainframe modernisation actually means
Stop trying to replace the mainframe. Start trying to make it queryable.
The pattern that works in every engagement we have run looks like this. The mainframe stays. A thin service layer in front of it, usually z/OS Connect or an equivalent gateway, exposes the existing business transactions as JSON endpoints. The LLM, the agent, the new web frontend, whatever the new thing is, calls the service layer. The mainframe team owns the contract. The new team owns everything above the contract. Neither team needs to know how the other’s stack works internally.
This sounds boring because it is. It is also the only pattern we have seen reach production. The reason is the operating model, again. The mainframe team keeps its quarterly deploy cadence. The new team ships weekly. The contract between them is the rate-limiting step, and it gets versioned like any other API.
Where the LLM actually adds value
The LLM does not sit between the mainframe and the user. That is the demo, and the demo does not survive contact with reconciliation. The LLM sits adjacent to the mainframe, in the workflows the mainframe was never built for.
An example from a recent engagement. The bank’s loan origination system was on a thirty-year-old mainframe stack. The mainframe was correct, fast, and audited. The problem was the intake form, which took an hour with a relationship manager and produced a PDF that a clerk re-keyed into the mainframe. The LLM did not replace the mainframe. It replaced the clerk. The intake form became a conversation, the conversation produced structured output, and the structured output called the service layer that called the mainframe. Cycle time went from a week to two hours. The mainframe code did not change.
This is the actual shape of mainframe modernisation with AI in 2026. The mainframe handles the regulated, audited, deterministic core. The LLM handles the messy, conversational, undefined edges. The service layer is the boundary, and the boundary is where the engineering investment goes. Not in either subsystem on its own.
We will keep watching for the engagement where the rewrite actually works. We have not seen it yet, and we are not betting on the next eighteen months being different.
Related: Schema drift is a contract failure, not a pipeline failure. The same boundary-first thinking applied to data.