How long does a mainframe-to-cloud migration typically take?

Timelines vary significantly by workload complexity and strategy. Simple rehosting of a single well-documented application can complete in months. Full core banking migrations — like Commonwealth Bank’s — take 18 months to three years with significant resources. Complex refactoring projects routinely take longer than planned. Planning for twice your initial estimate is not pessimism; it is calibration based on the available evidence.

How much does mainframe-to-cloud migration cost?

Migration costs vary enormously depending on workload complexity, strategy chosen, and whether the organization uses specialist migration partners. Simple rehosting projects can cost millions; full core banking refactoring projects cost hundreds of millions when you include partner fees, dual-running costs, testing, and staff time. TSB’s failed migration and its consequences cost the organization well over £100 million (approx. $120M) all-in (FCA Final Notice: TSB Bank plc, December 2022). Migration business cases should include full lifecycle costs, not just consultant fees.

Can all mainframe workloads be migrated to cloud?

Technically, almost any workload can be migrated given sufficient time and investment. The more relevant question is whether migration is economically justified for a specific workload. High-throughput, low-latency transaction processing workloads where mainframe economics are competitive, deeply embedded COBOL systems with poor documentation, and systems where migration risk is high relative to benefit are often better candidates for ongoing optimization than for migration.

Is it possible to migrate in phases rather than all at once?

Yes — and phased migration is strongly recommended over “big bang” approaches. The TSB failure was in part a consequence of a single cutover with no rollback option. Phased migration allows organizations to learn from early workloads before tackling the most critical ones, maintains rollback capability, and allows dual-running costs to be managed progressively.

What should we do about mainframe costs while planning a migration?

Implement mainframe FinOps. The planning and preparation phase for mainframe migration typically takes longer than organizations expect — and during that period, mainframe costs continue to run. Optimization during this phase funds the migration and builds the workload cost data needed to make informed migration prioritization decisions. Zetaly’s free ZAC simulation shows your MLC reduction potential from your actual environment data — a practical starting point for building that baseline.

What is the most common reason mainframe migrations fail?

Based on the available case studies, the most common cause is underestimating complexity — particularly the “exotic” components (non-standard languages, complex batch dependencies, undocumented integrations) that sit at the periphery of the main application. These are discovered late in the project, after timelines and budgets are set, and they derail schedules. Comprehensive upfront assessment — including automated code analysis — is the primary mitigation. See: mLogica — Avoiding Costly Mainframe Modernization Failures; Gartner — Too Big to Fail, April 2026.

Mainframe modernization guide

Mainframe to cloud migration: decide before you move

For some mainframe workloads, migration is the correct choice, while for others it is a costly error. The difficulty lies in determining which case applies before spending money.

Moving workloads that are currently running on IBM Z (such as COBOL applications, batch jobs, and transaction processing) onto public cloud infrastructure is what is meant by mainframe-to-cloud migration. For suitable workloads, it can reduce compute costs and accelerates delivery. But if done wrong, it can cause delays spanning years, cost more than the mainframe it replaced, and at times fail completely. The decision should be made at the individual workload level, not at the platform level, and it must begin with determining what each workload actually costs today.

When migration makes sense

When done properly and with an appropriate workload, migration is highly beneficial. It is true that the elasticity of the cloud actually reduces computing costs when demand is erratic and variable. Cloud-native tools—such as containers, continuous delivery, and DevOps—give you a release speed that the mainframe never could achieve. Moreover, you have access to a much bigger pool of talent than the dwindling number of COBOL workers. While migration is one way mainframe modernization, it is by no means the only option. Only those workloads that have variable demand, a clear interface with the rest of the organisation's systems, and a well-defined business case are suitable for migration.

What the business case usually leaves out

The business cases for migration may seem attractive on paper but fall apart in reality, because the difficult issues only surface later on. The projects can take longer and end up costing more than expected: both platforms operate side-by-side for months or even years, there are no straightforward cloud equivalents for the exotic components (such as Assembler, Easytrieve and IMS), and in a COBOL migration, the decades-old code contains the business rules which have never been documented anywhere. In regulated sectors, compliance adds further years. The most serious examples are public ones: When TSB Bank migrated in 2018, banking services were disrupted for a large proportion of its 5.2 million customers, and the bank received fines of £48.65 million from the FCA and the PRA (FCA). The claims that generative AI now makes migration easy are also largely exaggerated: Gartner predicts that over 70% of the mainframe exit projects that begin in 2026 will not achieve the benefits they were intended to, with the reason given being that the capabilities of generative-AI tools have been overestimated (Gartner).

Additionally, AI is now one of the fastest-growing areas in many mainframe budgets, and IBM is positioning the platform as a place to run AI inference rather than move AI workloads away from. See our blog on AI and mainframe cost.

The sources state that the fine imposed on TSB was £48.65 million in total (£29.75 million from the FCA and £18.9 million from the PRA), as reported on 20 December 2022 at fca.org.uk; furthermore, the Gartner press release of 18 June 2026 says that more than 70% of mainframe exit projects will fail because of an overestimation of the capabilities of generative AI.

Get the full decision framework for mainframe to cloud migration

For a more detailed picture of mainframe-to-cloud migration, download our migration guide: it includes a discussion of the four migration strategies and the associated trade-offs, real examples of both successes and failures, the hybrid model IBM is currently developing, and a workload-by-workload evaluation framework you can use in your own environment. Download it before putting together your business case.

Download the migration guide

The smarter first move: optimize cost and usage

“For many mainframe customers, GenAI can be more effectively used to enable modernization in place rather than accelerate migration off the platform.”

— Alessandro Galimberti, VP Analyst, Gartner (June 2026)

What most migration plans leave out is that you can't carry out the call unless you know how much each workload costs and how it behaves. What’s more is that the work required to gather that information is often the very work that makes migration unnecessary. So, before you move anything, establish two things.

Cost control

Monthly license charges, or MLC, are generally the biggest item in the mainframe operating budget, and they grow as your workloads increase (HCLTech). Currently, active mainframe FinOps (Financial Operations) helps to reduce this bill through Zetaly Automated Capacity (ZAC), which manages the Rolling 4-Hour Average (R4HA) billing peak that determines your monthly charge, typically decreasing MLC by 5 to 20 percent without changes to the applications. These savings remain with you whether or not you migrate, and they provide the funding for the migration if you decide to do so.

Usage visibility

You should have the ability to see what each workload actually uses, broken down by application and business unit, in order to decide which ones are worth moving. The Zetaly Data Platform (ZDP) gathers that operational data with mainframe overhead of less than 0.2%, and the Zetaly Service Intelligence (ZSI) converts it into dashboards that each part of the business can understand without the need for a mainframe specialist to interpret them.

Mainframe cost optimization involves reducing platform costs and clearly understanding what each workload requires. Once you have a cost baseline and an understanding of usage, migration decisions no longer rely on guesswork. Mainframe optimization can stand on its own, since the usual solution is to optimize in place and only move the workloads that actually provide a return.

Frequently Asked Questions

What does it mean to migrate from a mainframe to the cloud?

This involves moving workloads currently running on IBM Z, such as COBOL applications, batch jobs, and transaction processing, onto public cloud infrastructure. While it may reduce costs and speed delivery for certain workloads, high-throughput or deeply embedded systems are often slower, more expensive, and riskier than expected.

Does moving off the mainframe always result in cost savings?

Cloud computing is more economical for irregular, variable workloads. For high-throughput transaction processing that runs almost continuously, mainframe economics can be competitive if you account for network egress, storage, and the overhead of running cloud infrastructure. The true answer depends on the workload, not the platform.

How long does a mainframe migration take?

There is a great deal of variation; rehosting a single, well-documented application can take several months. Migrations of the entire core banking system take between 18 months and three years when you employ a lot of resources, and complex refactoring projects usually take longer than originally planned. When you plan for twice the amount of your first estimate, you are calibrating your plan against actual evidence, not being pessimistic.

What is the most common reason for mainframe migrations to fail?

Failing to take account of the complexity—particularly that of certain exotic components such as Assembler, Easytrieve, and IMS, which are located at the edges of the main application—leads to these issues being identified only late in the process, after both the budgets and the timelines have been set, and as a result delays the schedule. The best way to mitigate this is by doing a thorough assessment at the outset and incorporating automated code analysis.

Should I optimize my mainframe before migrating?

Yes. Optimizing cost and usage first builds the per-workload cost baseline you need in order to prioritize what to move and reduces your bill during the planning window, which often takes longer than expected. Mainframe cost optimization funds the migration and frequently shows that keeping some workloads in place is the better call.

What is the hybrid mainframe-cloud model?

Hybrid keeps the mainframe for what it does best — high-throughput transactions, regulated record-keeping, or near-continuous batch — and moves customer-facing and analytics workloads to the cloud, connected by APIs and data pipelines. For most large enterprises, it is the permanent mainframe cloud strategy, not a phase, and IBM builds for it directly.

Know what each workload costs before you decide what to move

The most common mistake in migration planning is building a business case without accurate mainframe cost data. Get the guide, get the baseline, and generate savings while you plan.

Download the migration guide Get a free ZAC Simulation Explore Mainframe FinOps