Beyond Mainframe Exit: The Case For Workload Motility

Insurance carriers need a more flexible approach than all-or-nothing mainframe exit. Workload motility is the discipline of continuously placing workloads on the platform that best aligns with business, cost, compliance and operational requirements.

Four articles into this insurance-focused series around the April 2026 Gartner® research titled “Too Big to Fail: Why Mainframe Exit Projects Are Likely to Fail in the Age of Generative AI,” the throughline should be clear:

• Mainframe exit was never the strategy. Generative AI doesn’t make mainframe exit easier — it makes poor strategy easier to execute, faster.
• Not everything old on the mainframe is technical debt; legacy and heritage systems need different playbooks entirely.
• AI is already earning its keep in code understanding and IT operations, while code conversion still demands heavy validation and governance.
• For regulated systems of record, the safer architectural default is increasingly bringing AI to the data rather than moving the data to the AI.

None of that adds up to “don’t modernize.” It adds up to a different operating model than the one most carriers are currently running. We call it “workload motility,” and this is what we think it takes to actually operate that way — not just believe in it.

From a Decision to a Discipline

Most mainframe strategies are still built around a single, large, one-time decision: exit or don’t, migrate or don’t, modernize or don’t. As we see it, the Gartner report’s guidance undercuts that framing. It describes different strategic paths for large, medium and small environments, and even within a single large environment, recommends a “platform-smart approach” built on continuously identifying and rehosting workloads to the most appropriate platform over the long term, not a single migration event.

We agree with that framing and think it should go further: workload placement isn’t a project with an end date. It’s an ongoing discipline, because the variables that determine where a workload belongs don’t hold still. Regulatory requirements change. Talent pools shrink further. New AI capabilities — like the on-platform inferencing made possible by hardware such as IBM’s z17 — change what the “best platform for this workload” even means. A workload placed correctly in 2024 may not be placed correctly in 2027 — and not because anyone made a mistake, but because the estate isn’t static and the decision shouldn’t be either.

The Variables that Should Drive Every Placement Decision

Workload motility replaces a single binary — stay or leave — with a repeatable evaluation across the variables this series has surfaced one at a time:

• Business criticality — Does this workload carry differentiated value (proprietary rating models, claims logic) or is it a commodity function?
• Cost — What does this workload actually cost to run, license and support where it sits today, versus elsewhere?
• Compliance exposure — What regulatory or statutory requirements attach to this workload’s data, and how do they change if it moves?
• Latency — Does this workload need real-time or near-real-time decisioning that argues for proximity to the system of record?
• Data gravity — How much accumulated transaction history sits behind this workload, and what would it cost, physically and financially, to move it?
• Resiliency needs — Does this workload require the resiliency, security and transactional integrity the mainframe delivers out of the box, or can another platform meet the bar cost-effectively?
• Modernization readiness — Is this a legacy application ready for retirement, or a heritage application that needs the incremental playbook this series has described?

Evaluated together, these variables point each workload toward one of several destinations: staying on the mainframe and being optimized in place, moving to cloud or distributed infrastructure, shifting to a SaaS replacement, or moving to a Mainframe-as-a-Service (MFaaS) consumption model. The point of workload motility is that this evaluation runs continuously across the estate, not once at the start of a migration project.

What this Looks Like in Practice

Operationalizing workload motility is where this stops being a philosophy and starts being a program. In our work with insurance and financial services carriers, that program typically includes:

• Estate assessment — A workload-by-workload inventory of what’s running, what it costs, what depends on it and how it scores against the variables above.
• Workload segmentation — Sorting the estate into legacy versus heritage categories, and further into candidates for optimization, migration, replatforming or retirement.
• MIPS and software cost optimization — Identifying top MIPS consumers and reducing consumption or offloading to specialty processors, freeing budget for the modernization that actually matters.
• ISV rationalization — Replacing or renegotiating expensive independent software vendor tools where lower-cost or better-fit alternatives exist.
• Operational modernization — Building the DevOps practices, API enablement and observability this series has described directly into the heritage estate.
• Execution across the hybrid estate — The ability to execute whatever the workload-level decision calls for, whether that’s staying on IBM Z, moving to cloud, adopting SaaS or consuming mainframe capacity as a service.

Where Ensono Fits

The IT services industry has spent decades on a simple equation: more work requires more people, and more people generate more revenue. AI is breaking that equation everywhere, not just on the mainframe — and the firms that only use AI to operate the old delivery model 10–20% faster will find that clients stop paying for effort long before they stop needing outcomes.

Workload motility is what an outcomes-based engagement actually looks like in this domain — not a team sized to a migration, but a standing discipline sized to the estate, priced against the placement decisions and cost reductions it delivers on an ongoing basis, not the hours it consumes getting there.

Ensono works with insurance and financial services carriers to run this discipline as an ongoing practice. We think this is a materially different engagement than a traditional migration project, and the difference matters more than it might first appear.

We also think this is a more honest way to frame what carriers actually need right now. The Gartner report’s findings make the risk of the alternative explicit: “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 answer to that risk is not avoiding modernization; it’s replacing the exit project with the discipline this series has described.

The Call to Action

If there’s one takeaway from this series, it’s this: Stop asking whether to exit the mainframe, and start building the capability to answer, workload by workload, where each one actually belongs — today, and on an ongoing basis as the answer changes. Exit is an outcome available to some workloads, but it’s not a strategy for the whole estate — and workload motility is how that distinction gets operationalized, one decision at a time.

This is the fifth and final 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

What is workload motility?

Workload motility is an ongoing discipline for deciding where each workload in a mainframe estate should run — mainframe, cloud, SaaS, distributed or MFaaS — based on business criticality, cost, compliance exposure, latency, data gravity, resiliency needs and modernization readiness. It replaces a single, one-time exit or migration decision with a continuous evaluation that adapts as the estate, regulations and available AI capabilities change. 

Why isn’t a one-time mainframe exit project enough? 

The variables that determine where a workload belongs — regulatory requirements, talent availability, AI capability, cost — don’t hold still. A workload placed correctly today may not be placed correctly in a few years, not due to a mistake, but because the estate and its environment kept changing after the project ended

What does operationalizing workload motility actually involve? 

In practice, a workload-by-workload estate assessment, segmentation into legacy versus heritage categories, MIPS and software cost optimization, ISV rationalization, operational modernization, and the ability to execute whatever placement decision results — on IBM Z, in the cloud, via SaaS or through an MFaaS consumption model. 

How does this change the commercial relationship between a carrier and a modernization partner? 

It shifts the engagement from a team sized to a migration project toward a standing discipline sized to the estate, priced against the placement decisions and cost outcomes it delivers on an ongoing basis rather than the hours spent getting there. 

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.