Somewhere in your organisation there is a system that everybody depends on and nobody wants to touch.

It processes the payments, prices the policies, or moves the stock. It has run for twenty or thirty years and has never lost a transaction. And every time the business asks for something new, such as a mobile channel or a faster quote, the answer comes back as eighteen months and a number with a lot of zeros.

That system is usually IBM Z or IBM i. The conversation about it usually gets framed as a choice between two bad options: keep paying for something the market calls legacy, or replace it and hope.

There is a third option, and it is the one most organisations actually take. Leave the reliable core alone and build the new capability around it. Mainframe modernization then becomes a series of decisions about boundaries, rather than one enormous bet.

Mainframe modernization is a boundary decision, not a migrate-or-stay choice 

The debate is usually framed as two positions. Ask instead which specific business capability is blocked and by what, and the list gets much shorter: usually three or four things, and few of them need the system that runs the company replaced.

Rip-and-replace commits you to a target platform, a switch-over date and a budget before anyone has finished mapping what the current system actually does. Modernizing around the core makes the same decisions one at a time, when you know more, and leaves you the option to stop.

A modernization strategy is credible when it can be halted halfway and still leave the business better off than when it started. That is the test the big-bang approach cannot pass.

What the data says – over 50% of mission-critical workloads stay on the mainframe 

The market data is consistent, and it does not say what the “legacy” framing implies. Organisations are moving selected workloads off these platforms. Very few are leaving the platforms.

Kyndryl’s 2025 State of Mainframe Modernization survey (500 senior IT and business decision-makers, fielded by Coleman Parkes) found that 56% of mission-critical workloads stay on the mainframe. Some 98% of respondents are moving work elsewhere, but on average that is 28% of their applications, and the 56% figure suggests the core is mostly not in it.

IBM i looks much the same. Fortra’s 2026 IBM i Marketplace Survey (320 respondents, published January 2026) found 41% planning no change to their IBM i footprint and 24% moving some or all applications off, up from 18% a year earlier. But only about 4% intend to move everything within two years, and 64% of those who say they are leaving have no plan to do so within two years. Leaving is, for most, an intention rather than a project.

The pattern in these failures is consistent, and it is rarely technical: one switch-over date, a new system that behaves differently once real volume hits it, and no rehearsed way back. The engineering is seldom the problem. The programme design is.

IBM Z modernization and IBM i modernization are one decision

If you run both platforms you have one budget and two sets of specialists who use different vocabulary and rarely reference each other. You end up mediating between two proposals written as if the other estate did not exist.

Treat them as one thing, the mission-critical core, because the business situation is identical on both sides. A system that handles the transactions the company cannot get wrong. Rules encoded over decades, often by people who have since retired. A shrinking group who understand how it works, and a business that needs to change faster than the core can safely be changed.

One point worth settling early, because it changes the tone of the whole discussion: neither platform is on a withdrawal path today, and both had a new release in 2025. IBM shipped a new mainframe generation, IBM z17, in June 2025, and a new IBM i release, 7.6, in April 2025, supported on both the current generation of hardware and the one before it. These are current products under active development. The question is not how long you can keep this alive, but what you should choose to run there.

What does have deadlines is the version you are on. Support dates are the one thing in this subject that is not a matter of opinion.

	IBM Z	IBM i
What it typically runs	High volumes of transactions, the overnight processing runs, core banking, policy administration	ERP and line-of-business systems in distribution, manufacturing and logistics, usually customized in-house over many years
Where the pressure comes from	70% of organisations in the Kyndryl survey struggle to find people with the right mix of skills; 39% are losing knowledge to retirements	Skills is the number one concern in the Fortra survey at 69%, ending cybersecurity’s nine-year run at the top
The nearest hard deadline	Standard support for z/OS 2.5 ends on 30 September 2026	Standard support for IBM i 7.4 ends on 30 September 2026, with a paid extension available to 2029. The paid extension for IBM i 7.3 runs out in 2028

Support calendars, not strategy documents, are what actually force a programme to start. Build that calendar before the roadmap. It separates the decisions with a date attached from the genuinely discretionary ones.

What to leave alone on IBM Z and IBM i: entry criteria for the “retain” decision 

This is the part almost nobody writes down, and it is what makes everything else safe.

The standard modernization frameworks offer much the same menu for an individual application: move it as-is, adjust it, rebuild it, buy a replacement, retire it, or leave it where it is. That menu is useful, and it is frequently mistaken for a strategy. It describes what could be done to one system. It says nothing about which systems to touch, in what order, or which to protect from the programme entirely.

“Leave it alone” is the least-defined option on that menu. Everyone lists it; most clients arrive without written criteria for it. Treat something as protected when two or more of these are true:

• Nobody can say what “correct” looks like. The business rules exist only in the code. There is no specification anyone trusts, no way to test the answers, and nobody left who can confirm the output is right. Rebuilding this is archaeology with a deadline attached.
• A mistake would reach a regulator. If a defect produces a wrong statutory return or an audit trail you cannot explain, recovery is not measured in engineering days.
• The platform is the right home for the work. Very high volumes of small transactions, answered in milliseconds, at a cost per transaction you can predict a year out. That is what these systems were built for. Move that work because you have a reason, not because it appeared on a migration list.
• It barely changes anyway. A system with a named owner, a tested recovery procedure and two change requests in three years is the part that works.
• You could not undo it. If you cannot run old and new side by side, compare the results and switch back during a planned weekend outage, you would have no way out. That makes it a business risk rather than an engineering one.

A “do not touch” list is a deliverable, not a gap in the plan. Publishing it early is what lets everything else move quickly, because nobody has to reopen the scope argument every month.

How to open up a mainframe safely, without rewriting it

Most of what the business is asking for does not require changing the core.

A customer portal does not need the policy system rewritten; it needs to read from it safely. A faster quote does not need new pricing logic; it needs that same logic reachable from a website or a phone, not only from the terminal screens the back office uses. Nearly every request in this category is really a request for controlled access to what the core already knows and already does. The technical name for this is API enablement, and it means putting a standard, supported doorway on a system that never had one.

There are four distinct jobs here, and treating them as one is how organisations end up with hundreds of fragile hand-built connections nobody owns.

What the business is asking for	The question to settle first	What it usually takes
“Let this new app use what the core already does”	Who owns this connection, what does it promise, and what happens when it fails?	A standard, supported doorway into the existing system. IBM supplies one for each platform, z/OS Connect on IBM Z and Integrated Web Services on IBM i, and neither requires changing the business logic underneath
“Tell other systems when something happens”	Does this event have a stable meaning, an owner, and a rule for how long it is kept?	Announcing events once, so any system that needs to know can subscribe later without someone building another one-off connection
“Let us report on and analyse this data”	Where does the data become authoritative, and who is allowed to see it once it has been copied somewhere else?	A controlled copy of the data, where every figure can be traced back to the original
“Make the process around it faster”	Which steps are real decisions, and which are just hand-offs?	Workflow and document handling built outside the core, not inside it

The first two get confused constantly, and the confusion is expensive. Sending a reliable instruction to one named system is a different problem from broadcasting news that several systems may want. The two common technologies here, IBM MQ and Kafka, are built for different jobs, and our IBM MQ vs Kafka decision guide works through where each belongs.

The AI question, without the product pitch

Two AI conversations get tangled together here and they have different answers.

The first is where the analysis happens. If you want AI involved in a transaction while it is happening, such as scoring a claim or flagging a payment, you either bring the model to the data or ship the data to the model. That is a real fork, with consequences for speed, cost and what compliance will permit to leave the building. IBM’s research with Oxford Economics (425 technology leaders, May 2026) found that only 21% currently run AI analysis alongside their core systems, while 38% think that is where it belongs. The study records the gap without explaining it. Either answer can be right for you, and either way it depends on getting data governance in place before scaling generative AI rather than after.

The second is whether AI can translate old code into a modern language and end the problem. It genuinely helps with understanding the code, and can convert selected pieces with tests that check the behaviour still matches; IBM’s own tool for this, watsonx Code Assistant for Z, is positioned exactly that way. It is not an unattended conversion engine for an entire estate. IBM’s study puts the limit plainly: 78% of the executives surveyed agreed that translating code on its own addresses only a small part of what the job requires. The data, the connections, the testing and the question of who operates the result are the programme. The code was never the hard part.

Sequence the work by how easily it can be undone

Every provider recommends a phased approach. Very few say what separates one phase from the next, which is why “phased” so often means the same big bang in installments.

The ordering principle that holds up is reversibility. Each stage should be undoable on its own, without depending on the previous one having been made permanent.

• Stage zero: find out what you have. Which systems and connections exist, who owns each in the business, what breaks if it stops, and which have a date attached. An integration audit is the usual way to do this, and it produces the protected list as well as the target list. Our guide to running one covers what it should capture.
• Stage one: let new systems read from the core. Open up access to information and existing functions without changing what the core does. If something misbehaves you switch off the new system and nothing is lost. Most of the visible business value tends to arrive at this stage, well before any rewrite.
• Stage two: let new systems update the core. New channels or processes that make the core do something. Reversible only if somebody designed the undo path before go-live, so make that a condition of approval rather than an afterthought.
• Stage three: change selected pieces. Individual functions rebuilt, run in parallel with the original and compared until you trust the result. Never the whole estate, and never without a way to check new answers against old ones.

Choose the first candidate for what it proves, not for how important it is. It should matter enough that success convinces the board, and be contained enough that the team can verify the whole business outcome and reverse it. A revenue-critical partner interface with undocumented rules is a poor first choice however straightforward it looks on a diagram.

A plan earns trust when it explains why something is staying put as clearly as why something is moving.

The mainframe modernization business case 

Be careful with the return-on-investment figures circulating in this market. The Kyndryl survey reports self-assessed returns of 288% for improving what runs on the mainframe and 362% for moving off it. Those are respondent estimates, collected by a company that sells both services, with no cost model shown. They tell you what executives believe, not what happened. The more useful finding, from the IBM Institute for Business Value study, is that only 14% of organisations consistently compare costs across platforms. Most business cases in this category rest on numbers nobody has reconciled.

A case that survives a finance review shows four things:

• What the platform actually costs you, based on your own capacity and contract rather than list prices.
• The cost of running both at once. This is the line most business cases omit and most programmes overrun on. If the transition takes three years, three years of parallel running belongs in the model.
• Your exposure if key people leave. Not as a survey statistic but as a named list: which capabilities depend on how few people, and when do those people retire? Fortra found 66% of IBM i sites running with fewer than three administrators. Recruitment does not fix that quickly.
• What speed is worth. The revenue or cost effect of the specific things stage one unlocks, in the language the business already uses.

A smaller number that shows its arithmetic will get funded ahead of a larger one that does not. The case is stronger still when it states plainly what the programme will not attempt.

What a mainframe modernization assessment should deliver 

Not a recommended product list, but a set of decisions someone can be held to:

• An inventory of the systems and connections that matter, each with a recommendation attached.
• A published protected list, with the reason each item is on it.
• A stage plan with conditions for starting, finishing and reversing each stage.
• An answer to who operates the result and how problems get found.
• Success criteria for stage one written as business outcomes, not technical milestones.

Coexistence belongs in that document explicitly. Parts of the estate will keep working exactly as they do today while new approaches are proven, and that is a planned state rather than an unfinished migration.

If the immediate need is to turn “we should probably do something about the mainframe” into a scoped first stage, legacy modernization services can produce the inventory, the recommendation per system and the sequence before anything irreversible is committed. Where the constraint is getting information and functions out of the core safely, data integration consulting is the closer fit.