AI Won’t Kill the Mainframe

IBM has become a stock market darling again of late, with its share price recently hitting all-time highs, largely powered by the mainframe, which had a box office last quarter, delivering 67% growth after the first full quarter of shipments for the latest z17 model. So, against this recent resurgence of IBM’s stock, for one Anthropic, highly reductive blog, focused solely on refactoring COBOL to cause IBM’s stock price to drop by 13% in a single day, its worst performance in 25 years, is big news. However, when COBOL makes the headlines, the nuance is thrown out of the window, and the fundamental issues that have helped the mainframe endure for 64 years, and counting, are ignored.

The conversation around the mainframe has been stuck in the same loop for years. People talk about it as if it were a relic. They assume every large bank or insurer is just one bad day away from moving everything to the public cloud. My analysis and conversation with clients is that this view is fundamentally flawed. For some context, I have spent half my career working for mainframe vendors such as IBM and Broadcom, and the last almost 5 years as a technology industry analyst tracking this space. I regularly get briefed by both sides of the modernization divide, with briefings from the heavily funded Mechanical Orchard, Astadia (part of Amdocs), Heirloom Computing, and, of course, AWS all being on my calendar in the last few months.

The simplistic and reductive nature of the Anthropic blog ignores the sheer physical and logical center of gravity of these systems. Moving them is not just hard; it is often illogical. What I am seeing now is a shift where the platform is not just surviving but is being architected to lead in the era of AI. I see AI as a tailwind for the mainframe, not the opposite.

My perspective is that we are moving past the era of the "rip and replace" strategy. For a long time, the only way to modernize was to leave the mainframe behind. That proved to be a recipe for massive budgets and even bigger failures. The annals of CIO tenure are littered with CIOs who have been booted out after failed mainframe migrations, only for their replacements to ditch the whole idea and double down on on-platform mainframe modernization. I recall chatting with the CIO of a UK bank that had spent 900m GBP trying to move off the mainframe and five years, only for the incoming CIO, with whom I met, to cancel the project and buy two new mainframes from IBM.

Based on my analysis of the market, and I talk to vendors on both sides, the introduction of generative AI has changed the math entirely. We are seeing a new model where AI is brought to the data, rather than the other way around. This is a subtle but massive change in how enterprise computing works. The IBM Spyre accelerator is a key component in this discussion.

Our in-depth perspective highlights a critical trend in AI for mainframe modernization. It is not about using AI to simply refactor COBOL and dump it on the cloud. It is about using generative tools to understand the business logic that runs the global economy and then modernize it, often times in-situ, to leverage the underlying unique hardware and security benefits of the mainframe.

Many of these systems have been running since the seventies. But again, this story is more nuanced than the clickbait headlines would have you believe. For British audiences, Trigger’s Broom is a classic analogy, where the roadsweeper has had the same broom for 20 years, all while changing the broom head 17 times and the handle 14 times. For international audiences, the Porsche 911 was launched in the same year as the IBM Mainframe and has undergone continual evolution, all while retaining its leadership as a paragon of performance automobiles. Put another way, nobody calls a modern 911 legacy, nor should they call the latest IBM z17.

The people who wrote the original code are retired. This created a knowledge gap that was previously hard to bridge. Although nuance is needed here also, research that I led at my previous research firm highlights that getting skilled mainframe talent is no harder than hiring security practitioners or AI developers, so this must be taken into account.

AI tools are now designed to read that code, document it, and even convert it into Java or other modern languages while keeping it on the same reliable hardware. This approach aims to deliver the best of both worlds. You get the speed and flexibility of modern code with the legendary uptime of the mainframe. When you look at the sheer volume of transactions these machines handle, it is clear why they persist. They are built for a level of input and output that would make a standard server rack sweat. My analysis suggests that by using AI to refactor code in place, companies can finally stop spending eighty percent of their budget just to keep the lights on. They can start innovating on the platform they already trust.

The logic here is centered on data gravity. Data is heavy. It is expensive to move and risky to expose. If you have petabytes of transaction history sitting on a mainframe, it is far more efficient to bring the AI processing power to that location. This is what the latest generation of hardware and software assistants aim to deliver. They are designed to make the mainframe act like a first-class citizen in a hybrid environment. It is no longer a silo; it is a hub. The IBM Spyre accelerator is a key component in this equation.  I spoke with the lead architects for this technology back in 2024 when it was announced. Fundamentally, it brings AI acceleration inside the box to deliver what I call “in-transaction AI.” to workloads on the mainframe.  Coupled with Small Language Models (SLMs) this can drive huge advances in applications like fraud scoring of credit card transactions, moving the paradigm from sampling of certain transactions to scoring of every transaction, which can move the needle for many financial institutions.  IBM has over 200+ uses cases for Spyre it has been working on with clients, according to my conversations with IBM execs.