Legacy mainframe: what ages and what does not

A legacy mainframe is not a risk because it is old. Its hardware and its operating system are replaced on a regular cycle, so the only old part is the code that your company has written over 50 or 60 years and still runs every day.

That code keeps working. However, the knowledge around it disappears when experts retire and when companies merge, and few companies still have one person who understands the whole system. This loss of knowledge is the risk you need to manage, and it is a different problem from the age of the platform.

What “legacy” means: the applications, not the machine

The word “legacy” is often applied to the whole mainframe, but it fits only one part of it. Hardware is replaced and not modernized, and the operating system follows the same rule. As a result, neither one is what mainframe customers mean by legacy.

The legacy is the application estate. A company that has written COBOL (Common Business-Oriented Language) programs for 50 or 60 years often no longer knows how many lines of code it has, yet those programs are its information system. The French word for legacy is “héritage”, and it describes the situation well, because an inheritance is something you built, that still works, and that you keep because it has value.

For that reason, mainframe legacy systems are not thrown away and written again. A full rewrite costs too much and is not realistic at this scale. Instead, companies remove the parts that no longer make sense and build new services on the same base.

IBM’s own pricing shows that old and new work share the same machine. In 2014, IBM announced Mobile Workload Pricing for z/OS to keep new workloads on the platform. A mobile transaction starts in an app on a phone and ends on the mainframe. Under this pricing, IBM subtracts 60 percent of the processor capacity used by mobile transactions from the MSU (million service units) values that set the sub-capacity charge (Value-4IT; Mainframe Watch Belgium). In other words, IBM made the new work cheaper to run next to the legacy.

You can see the two kinds of work side by side in Zetaly Automated Capacity (ZAC). In the customer example below, one partition has a rolling four-hour average (R4HA) of 2,232 MSU, of which 1,709 MSU is legacy work and 523 MSU is mobile work.

What is current on a modern mainframe

The platform under the legacy code is recent. IBM made the z17 generally available on June 18, 2025, with a Telum II processor that carries an on-chip accelerator for artificial intelligence (AI) (IBM). The matching operating system, z/OS 3.2, became generally available on September 30, 2025 (IBM).

Most sites are not on the newest version, but they are close to it. An upgrade takes so long that the next version is already out when the project ends. For this reason, some sites stay on an older release and then jump straight to the newest one. The upgrade work never stops, and a site that is behind is usually behind because the work cannot go faster.

The software around the operating system follows the same cycle. This software includes the Db2 database and the transaction monitors CICS (Customer Information Control System) and IMS (Information Management System). A typical application is a COBOL program that runs through CICS in real time or in batch, and that reads or updates data in Db2. When a customer uses a mobile app, the app calls those same transactions and reads that same data. The newest channel in the company therefore runs on its oldest code.

What ages badly on a legacy mainframe: knowledge

The code keeps running, but the knowledge needed to change it does not last as long. Three causes explain this loss.

The first cause is old code that nobody dares to touch. Before products such as Db2 and CICS were common, developers wrote their own equivalents in assembler, a language close to machine code. Some of those programs from the 1970s and 1980s still run today, and every mainframe site has some. They are critical and they work, but the person who wrote them left long ago without documenting the code or passing on the skill. Companies reviewed their systems before the year 2000 to check how dates were handled. That cleanup removed many of these programs, but not all of them.

The second cause is mergers. For example, one French banking group ran about 50 separate information systems 25 years ago and runs one today. Each consolidation kept the system of one or two entities as the base and dropped the others, so part of the history and the knowledge went with them. Many of the applications that nobody can explain today come from those consolidations. Teams work to remove these applications, and their number goes down over time.

The third cause is the way knowledge is divided. Large data centers have functional architects and technical architects. A functional architect knows one domain in depth (for example, the loan application in a bank) but cannot describe its links with card payments or cash withdrawals. A technical architect supplies the databases and transaction monitors that developers build on. Because each person knows one part, most companies have nobody who can draw the whole information system.

Some mainframe costs are never questioned either, because every company has applications that it will not limit. A bank does not limit the applications that bring in revenue (online banking, cash withdrawals, interbank payments), so if those applications need more MSU, they get more MSU. In the same way, a car manufacturer does not limit the applications that manage the just-in-time supply of parts, and an airline does not limit the applications that manage the time an aircraft spends on the ground. As a result, the capacity that these applications use is rarely reviewed.

The first step toward closing the knowledge gap is to make the estate readable. Zetaly Data Platform (ZDP) collects the operational data that the mainframe already produces, and Zetaly Service Intelligence (ZSI) turns that data into dashboards organized by business domain. As a result, each team sees what its workloads consume without a mainframe specialist to translate. Both products are part of Zetaly’s mainframe observability offer.

The skills question

Lost knowledge becomes urgent when an expert retires. The retirement itself can be planned, and a company that has not organized the handover has failed at human resources planning. The harder problem is finding someone to hand over to, and too often a company replaces one gray-haired expert with another.

The situation is improving, but slowly. In BMC’s 2025 survey of more than 1,000 mainframe professionals, 66 percent of respondents were millennials or Generation Z, up from 37 percent in 2018 (BMC), so young people are arriving. However, they still need time, because a good systems engineer takes five to six years to become fully competent on a platform this broad and this deep. Nothing shortens that time.

Data shortens a different part of the learning. A mainframe records its activity in SMF (System Management Facilities) records, and decoding them is hard even for an engineer with six years of experience. Decoding is also low-value work for that engineer, because it is learned once and applied once. ZDP decodes the records automatically, so the engineer does not have to learn the decoding. For example, a large bank in Brazil had hired about 15 young systems engineers and had told them to learn SMF decoding, and they saw no point in it. When Zetaly showed them the data already decoded and readable, they were stunned.

Documentation helps less than data. A document still has to be read and absorbed, and that reading takes time the company does not have. Decoded data, in contrast, removes work that adds no value for the customer. Even so, decoded data does not replace the years an engineer needs to understand the system.

What it costs to keep a legacy mainframe and what it costs to leave

Aging skills are one of the reasons companies give for leaving the mainframe (CIO). Leaving is possible today. Twenty years ago, announcements about leaving the mainframe were mostly talk, because no other infrastructure could carry the load. That infrastructure now exists, and some exits succeed. For example, Deluxe Corporation reports that it moved off a mainframe more than 50 years old in about 12 months, after an earlier attempt had failed (CIO).

However, cost and time have replaced technology as the obstacles. Exit projects run late and over budget (CIO), and Gartner predicts that more than 70 percent of the mainframe exit projects started in 2026 will fail to produce their intended benefits, because the capabilities of generative AI tools are overestimated (Gartner). Some failures are public. TSB Bank migrated its customer data to a new IT platform in April 2018. A significant proportion of its 5.2 million customers were affected, and the regulators fined the bank £48.65 million (FCA).

Zetaly sees the same delays among its customers. Two of them announced their exit about six years ago, and each time the maintenance contract comes up, they renew it for two or three more years. Their projects advance, but the legacy is still running.

Total cost of ownership (TCO) explains much of this gap between the plan and the result. A mainframe installation is one or two machines and their disk storage, whereas the same capacity on standard servers takes thousands of them. A business case that leaves out part of that cost therefore reaches the wrong answer. IT teams now calculate TCO more carefully than they did ten years ago, and as a result, exits launched on enthusiasm alone are becoming rare.

For these reasons, the decision to leave is better made workload by workload than for the whole platform. A good infrastructure manager puts each application where it runs best. Analytics and read-only data go to the cloud, intensive processing and very large batch volumes stay on the mainframe, and web applications go to Linux or Unix. Our mainframe to cloud migration guide explains how to make that decision.

A full exit remains hard because of the size of the legacy. The volume of code is enormous, and a rebuild needs someone who understands the whole system. Most companies no longer have that person.

The future of mainframe computers is hybrid

Because each workload goes where it runs best, the data center is becoming a mix of private cloud, public cloud, mainframe, and containers. In this mix, the mainframe keeps the heavy transaction and batch work and hands the rest to the platform that suits it. Software has to follow the same logic. For this reason, most Zetaly software is written in Java and runs in a container, on Linux, or on Linux on IBM Z, wherever you decide. ZAC is the exception, because it manages capacity on the mainframe and therefore runs there.

AI is part of this hybrid mix. Zetaly’s customers already use AI in production to write code and to analyze fraud on transactions. They also use it heavily in code conversion projects (such as COBOL to Java), and some of the converted code still runs on the mainframe. For their mainframe technical data, however, customers still rely on statistics, trend analysis, and anomaly detection. IBM built the z17 so that AI inferencing can run on the mainframe itself, with a stated capacity of more than 450 billion inferencing operations a day (IBM). Zetaly has no customer feedback yet on that use, and most customers rely on existing large language models (LLMs). Our article on AI and mainframe cost covers the effect on your bill.

Quantum computing is still early, and Zetaly expects it to join this mix beside the mainframe, taking the very large calculations it can finish in seconds while the mainframe dispatches the work and takes back control.

Frequently Asked Questions