Mainframe Modernisation: What Actually Works (And What Looks Good in a Deck)

The consulting pitch is always the same: your mainframe is a liability. It’s expensive. It’s hard to find COBOL developers. It’s holding back your digital transformation. Replace it with cloud-native microservices and everything gets better.

There’s enough truth in this to make it persuasive, and enough oversimplification to make it dangerous. Organisations that have done mainframe migrations at scale — and the ones that have made expensive mistakes doing it — will tell you the same thing: the mainframe is rarely the problem people think it is, and replacing it rarely solves the problems people hoped it would.

What Mainframes Actually Do Well

Before talking about alternatives, it’s worth being honest about what you’re replacing.

Modern mainframes — IBM’s z16 series, for instance — are not the green-screen relics of the 1970s. They run Linux. They handle Java and Python. They process transactions at rates that most distributed systems can’t match: a high-end z16 can process tens of thousands of transactions per second with five-nines reliability and sub-millisecond response times under sustained load.

Banks and insurance companies that run core systems on mainframes are not behind the times. They’re running workloads where the mainframe’s characteristics — consistent latency under extreme load, hardware-level redundancy, near-zero unplanned downtime — are genuinely hard to replicate in a distributed environment.

The accurate critique is narrower: mainframes are expensive (licensing, hardware, and specialist staff), they require COBOL or PL/I skills that are increasingly difficult to hire, and they’re difficult to integrate with modern development practices like CI/CD and API-first design.

The Common Modernisation Approaches

Lift and Shift to Cloud IaaS

Run the same workload on cloud infrastructure — effectively emulating the mainframe environment on virtual machines. Companies like LzLabs offer software-defined mainframe platforms that run COBOL programs without the hardware.

What this solves: licensing costs (potentially), hardware refresh risk, physical footprint.

What it doesn’t solve: the COBOL skill shortage, the difficulty of changing the business logic, the monolithic architecture that makes incremental change hard.

This approach is often positioned as a stepping stone rather than a destination. In practice, it often becomes the destination because the next steps are harder than the initial migration.

Replatforming (Refactor for Cloud)

Take the existing application logic and rewrite it to run on modern infrastructure — typically a combination of Java or Go microservices running on Kubernetes, with a cloud-managed database replacing the mainframe’s VSAM files or DB2.

This is where most migrations underestimate the actual task. COBOL programmes running on mainframes often contain decades of business logic — accumulated edge cases, regulatory handling, financial precision that was hard-won through years of production incidents. That logic is not always documented. It’s not always understood by anyone currently employed at the organisation. The tests that validate it often don’t exist.

Translating this accurately is a significant intellectual and engineering task. Automated COBOL-to-Java transpilers (there are several) produce code that is technically equivalent in most cases and subtly wrong in others. The subtly wrong cases in core banking or insurance processing are exactly the ones that matter most.

Strangler Fig Pattern

Rather than replacing the mainframe in one project, you progressively move capabilities off it — wrapping it in an API layer first, then routing specific transaction types to new services, leaving the mainframe to handle what it does best while new development happens entirely outside it.

This is typically the most prudent approach. It produces incremental value (new capabilities come online faster when they’re not blocked by the mainframe’s development cycle), it allows the mainframe workload to shrink organically as services migrate, and it manages risk by keeping proven mainframe code running critical functions while new code proves itself in parallel.

The limitation: it requires organisational patience. A strangler fig migration measured in years is harder to fund and govern than a big-bang replacement project with a clear end date.

Retain and Modernise

Accept that the mainframe stays for core transaction processing and invest in making it better-integrated with the surrounding ecosystem. Add an API gateway layer, modernise the developer tooling, containerise supporting workloads, and selectively rewrite the highest-friction components.

This approach tends to be underrated in vendor conversations (nobody makes money selling it) but is the right answer for many organisations. The mainframe’s reliability and transaction processing characteristics genuinely differentiate financial services businesses that rely on them, and the cost of replacing versus retaining is not always as clear as the consulting pitch suggests.

The Hidden Costs of Migration

The Testing Problem

You cannot safely migrate a core banking system without comprehensive regression testing. In many cases, the tests don’t exist — they’ve never been needed because the system hasn’t been substantially changed in fifteen years. Building the test suite is a significant project in its own right, and it often reveals that nobody knows exactly what the system is supposed to do in every case.

The Data Migration Problem

Mainframe data formats are not the same as relational database formats. EBCDIC encoding versus ASCII/Unicode. Packed decimal numeric formats. Variable-length records. VSAM file structures. Converting decades of production data accurately, including the edge cases accumulated over that period, is painstaking work.

The Cutover Problem

How do you cut over from a mainframe processing transactions in real time to a new system without losing transactions, corrupting data, or having an outage? For a bank with millions of active accounts, this is not a straightforward deployment problem. The parallel-running period — running both systems simultaneously and reconciling outputs — can last months and is expensive.

The Skills Problem

Mainframe skills are genuinely scarce and getting scarcer. But the migration requires people who deeply understand both the mainframe and the target platform. That combination is even rarer. Organisations that don’t budget realistically for this typically discover partway through the project that they’re paying much more than planned for the people who can actually do it.

What the Successful Migrations Have in Common

Looking at organisations that have completed mainframe modernisations without catastrophe — and there are some — a few patterns emerge:

They started with inventory. Before deciding what to replace, they documented what was actually running. Application by application, business function by business function. The ones that skipped this step typically discovered halfway through migration that they’d missed something important.

They picked boring target architectures. The temptation when escaping a mainframe is to build something modern — event-driven, microservices, serverless. The migrations that went smoothly mostly chose conservative targets: well-understood database technology, mature application frameworks, deployment patterns with a long track record. The migration itself was enough novelty; adding architectural novelty compounded risk.

They moved non-critical workloads first. Reporting systems, batch jobs, ancillary applications. Build the migration muscle, validate the tooling, discover the unexpected problems — on workloads where a problem doesn’t take down core business operations.

They kept the mainframe longer than the original plan. Most migration projects have a planned decommission date that turns out to be optimistic. The organisations that planned for this possibility maintained flexibility rather than creating hard dependencies on the mainframe being gone by a specific date.

The Honest Question to Ask First

Before starting a mainframe modernisation programme, the honest question is: why are you doing this?

If the answer is “cloud is the future and mainframes are old,” that’s not a business case. It’s a fashion statement.

If the answer is “we can’t develop new features fast enough because everything runs through the mainframe and the change process takes three months,” that’s a legitimate problem — but the solution might be an API abstraction layer rather than a full migration.

If the answer is “our mainframe licensing costs have reached the point where migration costs less over five years than staying does,” that’s a real calculation worth making carefully.

The mainframe has been being replaced “soon” for about thirty years. It keeps running because the workloads it runs are hard to replace without also replacing the institutional knowledge that grew up around running them. Taking that seriously is the starting point for a migration plan that has a chance of succeeding.