Here’s the context. Physical mainframe hardware is routinely refreshed every 3 to 5 years, but the underlying software and core logic in large-scale organisations, especially in banking and insurance, often dates to the 1960s and 1970s. In fact, 40% of large UK financial institutions maintain legacy code written over 50 years ago.
Meanwhile, there is a looming skills gap associated with legacy mainframe systems. The issue (commonly coined within the industry as the Silver Tsunami) sees veteran COBOL experts reaching retirement, leading to organisations grappling to maintain decades old, highly complex codebases. In parallel, modern technologies such as AI, cloud and DevOps have advanced, requiring the mainframe to keep pace and integrate.
Many organisations are trapped between wanting to modernise or migrate to stay agile, and the severe operational risks involved in changing tightly coupled, monolithic applications.
None of that is a crisis though. It's a window. The people who understand these systems are still here, the platforms are more capable than they've ever been, and the tooling to connect them to everything else finally exists. Organisations that use the next few years well will come out with an estate that's cheaper, better documented and genuinely easier to build on.
This paper sets out how we think about that work, and how we help clients build a mainframe strategy. We've written it through a real-world lens – the cost pressure and complexity senior leaders are actually contending with, not the version in the vendor deck.
A brief history of the mainframe
Mainframe computing grew out of efforts in the 1940s and 1950s to automate complex calculations and business data processing. With the arrival of IBM and the introduction of influential systems such as the 701 (released in 1952) and 650 (released in 1954), businesses were able to automate payroll, accounting, inventory and customer records for the first time.
In 1964, IBM launched what many historians consider the most influential mainframe family ever – the IBM system/360. Its innovations included a compatible family of computers ranging from small to very powerful, software that could run across different models, standardised peripherals and support for both scientific and business computing. Previously, upgrading to a more powerful computer often required rewriting software. With System/360, organisations could grow without starting over. This compatibility became a defining feature of modern computer architecture.
During the 1960s and 1970s, mainframes introduced concepts that are now commonplace such as multiple users logged in simultaneously, interactive terminals, virtual machines, and resource sharing. For example, IBM’s CP/CMS pioneered virtualisation technology decades before cloud computing became widespread.
Today, IBM with the flagship IBM Z, is by far the largest supplier of mainframes with an estimated market share between 90% and 95%. Current IBM Z systems are designed for financial transaction processing, banking and insurance, hybrid cloud integration and AI workloads to name a few. IBM z16 is the primary workhorse for most top-tier UK enterprises, with z17 being the newest iteration, and z15 typically maintained as a secondary or disaster recovery system. The nearest rivals to IBM are Unisys (with ClearPath Forward) and legacy Fujitsu/ICL machines.
Why the Mainframe has survived and thrived
Many of the world’s largest financial institutions, governments, and retailers continue to rely on mainframes. The reasons hold up well:
- Exceptional reliability.One of the biggest advantages is continuous operation. Modern IBM Z systems are designed for continuous service, fault-tolerant hardware, hot-swappable components and planned maintenance with minimal disruption. For banks or airlines, even a few minutes of downtime can cost millions.
- Massive transaction processing.This remains their defining capability. A single modern mainframe can process enormous numbers of secure business transactions while maintaining data consistency. Example workloads include payments, trades, and insurance claims. These systems excel at online transaction processing (OLTP) where millions of users may access the same data simultaneously.
- Security.Enterprise mainframes include hardware encryption, secure key management, fine-grained access controls, comprehensive auditing, strong identity management, and isolation between workloads. Many industries with strict regulatory requirements continue to rely on mainframes for these reasons.
- Vertical scalability.Mainframes are designed to make one machine increasingly powerful. Instead of managing thousands of separate servers, organisations can consolidate many workloads onto one highly capable system. Benefits include simpler administration, lower networking complexity and predictable performance. Note that cloud platforms generally take the opposite approach – adding more servers rather than making one server larger.
- Backward compatibility.Perhaps the most remarkable feature is software longevity. Organisations can often run applications written decades ago with relatively few changes alongside modern workloads. For businesses that have invested heavily in legacy software, this reduces migration risk. Very few computing platforms offer comparable long-term compatibility.
- Efficient virtualisation. Mainframes pioneered virtualisation long before it became mainstream. Today they can host thousands of virtual machines, multiple operating systems, Linux workloads, and traditional enterprise applications. Their virtualisation is known for low overhead and strong workload isolation.
Common challenges and comparisons with cloud computing
If you're running a mainframe today, or weighing one up, much of this will be familiar.
Mainframes require significant investment in hardware, software licensing, maintenance, specialised storage, and networking. Moreover, in our experience, lack of transparency from suppliers’ disguises cost levers, making it difficult for some organisations to keep costs down. Although they can be cost-effective for very large workloads, they are generally not economical for small and medium-sized organisations. By contrast, cloud computing typically offers lower upfront cost with an ongoing pay-as-you-go model.
As noted in the introduction, the modern mainframe market is dominated by IBM. x86 servers however are available from many manufacturers, and organisations can choose from multiple cloud providers. This lack of mainframe supplier portability perpetuates the cost reduction challenge. Organisations often become deeply invested in hardware, operating systems, databases, transaction monitors and operational processes. Changing platforms can be expensive and risky, making long-term dependence on a single vendor more likely.
Experienced professionals in areas such as z/OS administration, COBOL development and mainframe operations are becoming harder to recruit as many specialists retire. At the same time, newer engineers are more likely to be trained in cloud-native technologies.
Although modern mainframes support Linux, containers, open-source software and modern programming languages, the surrounding ecosystem is still much smaller than that of cloud-native platforms, with newer software products targeting cloud deployments first.
Mainframes are not ideal for every workload. They are less well suited to web startups, rapid experimentation, short-lived applications, large-scale media streaming, or massively distributed microservices. These workloads often benefit from cloud native architectures.
Going forward, the comparison should be less about “mainframes versus everything else” and more about choosing the right platform for the workload.
Modern mainframes compete primarily with large clusters of x86 servers, cloud platforms, and high-end enterprise servers based on architectures like ARM or POWER.
The below table provides a side-by-side comparison:
Mainframe in the Cloud and managed services
When people talk about hybrid architectures, they are typically referring to a ‘cloud-connected mainframe’ i.e. where the physical mainframe remains in a data centre but is integrated with cloud services. This then allows new workloads to be deployed in the on-premise mainframe or in the cloud.
An alternative to this is for mainframe workloads to be rehosted in the cloud. Applications are moved from the mainframe to cloud infrastructure without major functional changes. This may include running COBOL applications on x86 servers or ARM servers, emulating aspects of the mainframe runtime or migrating databases and middleware to cloud. The lower hardware costs are appealing, along with easier integration with cloud tooling, and broader availability of infrastructure. However, it is common to encounter challenges with performance, compatibility and heightened test requirements. A starting point for an organisation considering this may be to move environments such as development and test to the cloud which may help reduce cost and risk by providing the flexibility to ‘spin up and spin down’, helping to minimise wasted spend from underused environments. The business case for this is typically built around savings from reductions in LPARs, CICS subsystems, MSUs and FTE support.
Another option is to replace the mainframe with cloud-native applications. This is where applications are rewritten for the cloud. Data models may be redesigned or historical data migrated. This can deliver greater flexibility but also requires significant investment and carries substantial delivery risk.
A further consideration is the hosting provision of the mainframe. Many large organisations employ internal ownership and co-sourcing whereby they own the hardware and software licenses, keep the mainframe in their own secure data centre, but heavily rely on co-sourced third-party contractors for day-to-day operations, maintenance and system monitoring. Other large enterprises prefer to completely offload the burden of data centres, hardware refreshes and niche staffing. They transfer their equipment and operations to a vendor-managed environment or use Mainframe-as-a-Service (MFaaS). This is conceptually similar to infrastructure outsourcing, but with cloud-like commercial and operational models. The approach benefits from reduced capital expenditure and access to specialist operational expertise, but it places dependence on the provider, and there are considerations around data residency, potential regulatory approval, and network latency.
Designing for the long term
Mainframes have been written off repeatedly for decades, and they're still here – largely because many organisations value stability over replacing systems that already work well. At the same time, they are no longer the default choice for new applications. Most new software is developed for cloud environments, and many organisations adopt a hybrid strategy in which the mainframe continues to run critical transaction processing while cloud services provide web applications, analytics, AI and customer-facing functionality.
For large organisations such as those in Financial Services, the question is not “should we keep the mainframe?” but rather “what role should the mainframe play in a modern enterprise architecture?”
That architecture should answer to a clear set of design objectives:
Considerations for developing a mainframe strategy
Every mainframe strategy has to fit the organisation it's written for. These are the questions we find are worth answering early.
- Decide what belongs on the mainframe:one of the biggest architectural mistakes is assuming everything should move to the cloud – or that nothing should. A useful principle is to match workloads to the platform that suits them best, noting that the mainframe should be a trusted system of record and cloud is typically a system of engagement.
- Expose business capabilities through APIs:historically many organisations relied on screen scraping, file transfers, batches interfaces and point-to-point integrations. These approaches create complexity and limit agility. By creating APIs for capabilities such as account enquiry, payments, customer lookup, balance checks and loan servicing, the mainframe increasingly functions as a secure provider of business services rather than as a closed, isolated platform.
- Shift toward event-driven designs:Examples include payment received, trade executed, fraud detected. By publishing these events, it allows downstream systems to respond on near real time without tightly coupling applications.
- Maintain a single, consistent copy of customer and account data:to support operational integrity and advanced analytics maintain the mainframe as the authoritative source for critical transactional data. Replicate only the data needed for analytics, AI and reporting. Use streaming technologies where low latency is important. Apply strong governance and lineage across all copies of data.
- Consider where AI workloads are most effective:typically, the mainframe should remain the source of trusted transactional data, with data streamed or replicated to AI platforms. AI models then generate predictions or recommendations, and the outputs are fed back into operational systems for execution. This avoids moving the transaction engine while still enabling advanced analytics.
- Design for people, not just systems: as cited, many financial institutions face an ageing workforce with deep mainframe expertise retiring. Practical steps include cross-training, introducing modern development tools and documenting knowledge gaps in legacy systems/business rules.
- Total cost of ownership should be evaluated over many years rather than focusing solely on infrastructure costs:in some cases, replacing a stable mainframe workload may cost more, for example, through migration effort, downtime risk, and cloud consumption costs, than continuing to run it.
Clean Mainframe
The term ‘clean mainframe’ has been increasingly heard across the industry in recent years, and it’s often misunderstood. It isn’t about rewriting everything in a modern language and eliminating COBOL. Many clean mainframe environments continue to run significant amounts of COBOL because it remains reliable and well suited to transaction processing. The idea is simpler than that: simplify an estate that has typically been running for 50+ years and has become inefficient and risky due to legacy processes and lack of decommissioning.
Six things characterise a clean estate. All of them belong inside a wider mainframe strategy rather than as a standalone exercise.
- Clear business purpose– every application should have a defined business owner and a justified reason for remaining on the mainframe.
- Reduced technical debt– over many decades, many organisations accumulate duplicate programs, unused jobs, redundant interfaces and dead code. A clean mainframe programme seeks to identify and remove these where it is safe and practical to do so.
- Modern development practices– historically, some mainframe environments used manual change processes and separate tooling (often, non-standard tooling at that) from the rest of the enterprise. A clean mainframe aligns with modern software engineering by using Git-based source control, automated builds/testing, and continuous integration and deployment.
- Good observability– a clean mainframe provides visibility into system health, performance, transaction latency and resource utilisation, to name a few. Monitoring must integrate with the organisation’s wider observability platform, so operations teams have a consistent view across mainframe, cloud, and distributed systems.
- Strong documentation and governance – essential for effective change management and resilience planning. A clean estate answering the questions of who owns each application, what business process it supports, the interfaces it exposes etc.
- Rationalised application portfolio – Many organisations discover that they have multiple applications performing similar functions or features that are no longer used. Sometimes it’s a case that legacy systems are being retained after mergers or acquisitions. A clean mainframe programme often includes consolidating or retiring unnecessary applications to simplify the overall estate.
How emagine can help your organisation
emagine is one of Europe's leading business and tech consulting firms, delivering complex business and technology transformation programmes across all major industries. We combine our own high-calibre consultants with a curated global community of specialists which means we can assemble and lead the right expert team for the problem in front of us. We call this providing the A-Team, every time.
That model matters more on mainframe work than almost anywhere else. The scarcest thing in this market is deep platform expertise, and our approach to sourcing it is the reason we can put z/OS, COBOL, DB2 and sourcing specialists alongside strategy and delivery leadership on the same team.
Our work spans four areas:
Strategy & Architecture:We develop pragmatic strategies and implementation roadmaps grounded in achievability and affordability.
Operating Model: We design new ways of working that balance internal capabilities with external services to reduce total cost of ownership.
Change Delivery: We lead large-scale transformation programmes using structured approaches. We manage business-critical transitions, providing technical and operational leadership from concept to implementation to ensure modern solutions deliver the intended outcomes.
Strategic Sourcing: We bring deep knowledge of the supplier landscape, supporting the full sourcing lifecycle from initial strategy through to exit management.
Whether you need support with developing a mainframe strategy, defining a new service model, delivering mainframe rationalisation or modernisation improvements, or even sourcing a new mainframe supplier, our track record speaks for itself.
We recently supported one of the UK’s largest Life & Pensions providers with a strategic review of its mainframe estate. We performed an in-depth investigation into system software, MSU consumption, programming languages and DB2 databases. We then conducted a commercial assessment examining system/infrastructure costs and software licence costs. We developed a set of opportunity areas and implementation approaches, before prioritising into a clear set of recommendations over a 5+ year timeline. Our transformation roadmap and commercial case centred on cost reduction, business enablement, risk reduction and efficiency.
Just some of the outcomes delivered included:
For another of our large clients, we were trusted to lead the migration of their IBM z series mainframe to a new on-premise datacentre implementing several modernisations simultaneously, including an upgraded processor for enhanced performance and security, and changes to mainframe storage tiers to achieve lower cost disks and larger capacity.