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 reduces compute costs and accelerates delivery, but for inappropriate ones it results in delays spanning years, costs more than the mainframe it replaced, and at times fails completely. The decision should be made at the level of the individual workload and not at the platform level, and it must begin with determining what each workload actually costs at the present time.

When migration makes sense

When done properly and with an appropriate workload, migration does prove successful. It is true that the elasticity of the cloud actually reduces computing costs when demand is erratic and variable. The use of cloud-native tools—such as containers, continuous delivery, and DevOps—gives 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 of modernising the mainframe, 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 seem very attractive in writing but fail in reality since the difficult issues appear only later on. The projects take longer and end up costing more than had been 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 the decades-old COBOL 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). And regarding the latest argument that generative AI now makes migration easy, this claim comes before any actual tools are available: 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 generative-AI tools have been overestimated (Gartner).

AI also affects the other area, since it is now one of the fastest-growing areas in many mainframe budgets, and IBM is presenting the platform as a destination for AI inference rather than one to leave. 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 a more detailed account of mainframe-to-cloud migration,download our migration guide: an exploration 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 prior to 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 the fact that you can't carry out the call unless you know the cost of each workload and how it behaves—and the work required to gather that information is often the very work which makes migration unnecessary. So before you move anything, establish two things.

Cost control.

The monthly license charges, or MLC, are generally the biggest item in the mainframe operating budget and increase 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, usually leading to a decrease in MLC by 5 to 20 per cent without any need to make 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, if you are 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 which each part of the business can understand without the need for a mainframe specialist to interpret them.

Mainframe cost optimization involves reducing the platform's costs and obtaining a clear understanding of what each workload requires. Once you have a cost baseline and an awareness of usage, then the decisions about migration cease to be based 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 migration 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?

It shows a great deal of variation; rehosting a single, well-documented application can take as long as months. Migrations of the entire core banking system take between 18 months and three years when a lot of resources are employed, and complex refactoring projects usually take longer than originally planned. When you plan on 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 failling?

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 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 primary way to mitigate this is through a thorough assessment at the outset, 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 to prioritize what to move, and it 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, near-continuous batch — and moves customer-facing and analytics workloads to cloud, connected by APIs and data pipelines. For most large enterprises it is the permanent operating model, 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