AI-powered mainframe exits are a bubble set to pop

Most mainframe users who turn to AI for help migrating legacy code to alternative platforms are going to be very disappointed, according to analyst firm Gartner. “More than 70 percent of mainframe exit projects initiated in 2026 will fail to produce the intended benefits due to an overestimation of generative AI tooling …

[Jamie Jones]

Gartner

Stopped clocks. etc.

[phuzz]

Re: Gartner

Wishing the three authors of this study good luck in the job market, because they won't last long at Gartner pointing out the emperor’s lack of clothes.

[Bebu sa Ware]

Re: Gartner

"pointing out the emperor’s lack of clothes."

… and his limited endowment.

[Slant Four]

yeah..nah

"Gartner’s opinion will go down very well at IBM, which saw its stock price slide sharply after Anthropic touted the COBOL-conversion powers of its Claude Code tool, sparking yet another round of speculation that the mainframe might be on its last legs."

These AI knee jerk reactions in the stock market to any AI "new shiny" are crazy.

And in this case, any techie in the industry knows that if these mainframe applications could have been moved they would have already and we have discussed this in other articles: Cobol conversions are the easy bit and are a small part of the pie. It's all the MF stuff around the cobol code that is the sticking point plus what other platform provides the same uptime?. The cloud sure doesn't. The only logical choice would be IBM P-Series running AIX if you wanted to get close to mainframe uptime.

And yet the great unwashed want to "believe" there is a there there... but there isn't.

Like all those ERP migrations that go south, never to be finished (with significant budget overruns), that would be the project profile for any company using AI to get them off the mainframe. There are so many dark arts/nooks and crannies in a mainframe application stack that AI won't have any training data to resolve these.

In my past (as a 15 year ex-IBM'er), I have done lots of migration assessments for MF customers and in the end the risks were always too high (irrespective of the cost) and I have been called into numerous non-IBM staffed conversion projects that had gone south... and that's where they stayed.

Bluck

[williamyf]

Re: yeah..nah

In reality, a PRIVATE cloud can get a similar uptime and performance to a mainframe if properly engineered.

Problem is, that's rarely the case. Not many people know how to do it right. And if the organization has people on their employ who can, they are blocked by inertia, lack of funds or less enlightened colleagues

[Anonymous Coward]

Re: yeah..nah

You say Private Cloud, I say On-prem.

[williamyf]

Re: yeah..nah

On-Prem and Private Clouds are very different beasts. A private cloud is also on-prem but gives you SIGNIFICANTLY GREATER control.

Amazon Outpost is On-Prem, yet, amazon decides the exact hardware configurations you are allowed to use (They have only three options) and the servers are amazon designed, made by pre-selected ODMs (IIRC only wynn and quante), the hardware upgrade schedule and the Cloud Software Upgrade/Update Schedule.

https://docs.aws.amazon.com/outposts/latest/userguide/outpost-maintenance.html

Meanwhile, in a Private Cloud scenario, you decide the hardware config, from whom to buy the servers, what cloud sw to use, and when patches are applied (microsoft has some vetted configurations but gives you more options and more latitude negotiationg with the likes of Dell, HP, and Lenovo).

Both on-prem, but private cloud gives MUCH MORE control for you.

You can also have on-prem some non-cloud workloads, instantiated on bare metal or virtual servers, probably working as pets instead of cattle, with no Elasticity, no centralized orchestation and other things that go beyond virtualization to true cloud-dyness.

[Filippo]

Correct me if I'm wrong, but I believe that a big part of why we still have decades-old COBOL applications running is that they are in sectors where correctness is critical, and the deploy-now-fix-later prevalent attitude is useless for them. LLM-generated code and "correctness is critical" are not really two things that go well together.

[Aitor 1]

I disagree

AI is excellent at translation.

It will be able to move from one language to another, particularly away from mainframes, if we consider COBOL.

Also, there will be few if any benefits, as this is translation, not migration. So no advantage taken from newer frameworks, objects, etc.

The only benefit will be running it on a cheaper but less reliable platform.

[DJO]

Re: I disagree

The coding isn't really the problem in MF migration, mainframes do not do a lot of heavy processing instead they tend to move a lot of data around very very quickly and at the moment only mainframes have the necessary I/O capabilities for these tasks although that is slowly changing.

Consider a Telco, they have thousands of calls of various kinds made every second and they all need to be recorded accurately as and when they happen, no (current) x86 solution is going to be able to cope with that amount of traffic.

[Anonymous Coward]

Re: I disagree

Well you are wrong.

The Telco I worked for used x86 and similar kit to "record calls". But all they recorded was the start and end of the calls, not the actual speech, with the kit effectively sitting inside the Telco voice network.

They also used x86 kit for their call centre solution. That handled over 20,000 simultaneous calls per second. And it recorded the speech of every call received.

But they still had mainframe, with multiple OS images and databases. The mainframe managed all the real heavy lifting, all the back end transactions when you ring up to move house, change provider. The transactions where vast quantities of records need to be updated and transactions pushed out to noddy x86 systems to propagate the changes out in the network.

They did look at replacing the mainframe applications, but only a few were migrated off. Just the relatively simple, infrequent stuff like billing, that only happens once or month or once a quarter.

[DJO]

Re: I disagree

Well the telco I worked for had (several) data centres full of IBM and Fujitsu metal, multiple robotic tape libraries and a host of other overpriced toys. While x86 may well be (and probably is) used at the exchange level to agglomerate the raw data, the real work was done on big iron. Perhaps you worked for a smaller telco. :-)

I just used telcos as an example, there are several use scenarios for which mainframes are the optimal solution or replacing them is more trouble than the benefit gained, but I'll agree that pool is diminishing year by year. That's not to say new uses for mainframes cannot arise, the way things are going the ability to handle absurd amounts of I/O is always going to be wanted by somebody.

[druck]

Re: I disagree

AI is excellent at translation.

Translation can be done 100% deterministically without using a LLM, but your point about the difference between translation and migration is sound.

[Anonymous Coward]

Re: I disagree

Natural language translation isn't deterministic, you need to include context for an accurate translation. And sometimes the point is that words have multiple meanings which makes the text untranslatable unless you come up with a new pun. And that's just in general, AI or an LLM won't change it.

[druck]

Re: I disagree

We were talking about programming language translation, specifically COBOL, rather than natural language.

[Aalbers]

There is a deep misunderstanding regarding migrating off the mainframe. Most people believe the issue is that migrating the COBOL code to a modern language is extremely difficult. That is not the case. The issue is migrating off DB2 (or any other mainframe database) and CICS. DB2 on the mainframe is actually a very good database with great availability features and it scales like no other. That means that even if you migrate your app to a different language, you are likely to run into serious performance issues.

People with no mainframe experience believe that migrating to a large Oracle Exadata server will solve any issue. They are wrong. I have seen customers moving from an Exadata server to small mainframes with less CPUs and delivering much better performance at a lower cost. If you need to run a large SQL database with high concurrency, there is no platform like the mainframe.

In conclusion, if you have mainframe apps that run on the mainframe and that do not have high scalability and availability requirements, go for it. Migrating is not that difficult and AI will help. Otherwise, do not even think about it.

[Jamie Jones]

I have no mainframe experience, but what you just wrote reminds me of the drive in the late 90's / early 2000's to migrate everything off unix to the wonderful windows.

My despair and levels of "I told you so" were probably similar to yours.

I'd never dare even consider a mainframe migration because i know sod all about the way they run, but (especially where i worked at the time) clueless people tried to move everything onto windows. It failed spectacularly!

One particular project was a web proxy for a building of about 1,000. It was given a 10,000 pounds rack mounted windows pc. I think they were just using Netscape server on it. it was delayed, was unreliable and eventually became semi-officially replaced with the old unused 486 that i shoved freebsd/apache on out of frustration!

Semi-officially? The windows setup was abandoned. and my apache setup was given the official proxy ip address. But i don't think the suits from head office ever knew. They certainly didn't know when on a planned ceremonious visit to our office, their demonstrated Internet access was through the 486 and not the windows server they had championed.

And there was nothing clever or special about what I did - anyone who recognizes the correct tools for a job could have done it.

[Anonymous Coward]

Microfocus tools are useful

A different company now owns the Microfocus COBOL tools and "Microfocus Enterprise Server". The Microfocus Enterprise Server is a mainframe lookalike on Linux. So it has a Spool, it supports connections from 3270, it supports CICS applications, it runs your JCLs, it supports VSAM and sequential datasets. I know several companies who are moving to Linux using this product.

The Microfocus pitch is quite good - first you come for the COBOL development environment on Windows, then once you're convinced that you understand your COBOL environment, you lift and shift to the Microfocus Enterprise Server. This all existed before AI...

[Bebu sa Ware]

"difficulties finding staff to operate mainframes,"

I would imagine if you recruit graduates, train them up, sign them to long term contracts binding on the employer with renumeration linked to total C-suite compensation, then you wouldn't have this difficulty.

In future attracting anything - other than a complete retard - to the IT sector, especially the more technical areas, will be nigh on impossible given the extremely shabby treatment recently meted out to the retrenched, by enterprises intoxicated from sucking the spiked lemonade from the AI tit.

Commitment has to work both ways or nothing works for long.

[Frodo]

Works both ways

A pre requisite to migration would be AIs ability to understand the code and the complexity.

But that solves the single biggest reason to migrate, which is skills, and understanding of legacy installations.

The better the AI the better viability - a shot in the arm - for existing mainframe estates.

[CoaxCoax]

Anyone else read "mainframe exits" and thought this was about customizing JES2?

[mikepren]

If ykyk

First job 40 years ago. Skills i learnt then have been used my entire career, including 10+ years doing cloud

[lordminty]

Ha

You are showing your age there!

Are you looking for a job? I've heard mainframe work can be very lucrative...

[DS999]

Actually 30% succeeding would be a huge win

Pretty sure fewer than 30% succeed now with humans in the loop. How many times have we read about government or big corporations canceling a massively over budget and over schedule mainframe migration project?

Maybe the ones AI succeeds at are the same types that humans succeed at, and the ones both fail at are failing for the same reasons - can't track down all the corner cases so the new system is woefully inadequate, failure to win buy in from the end users, etc. No amount of AI, not even AGI, can solve those problems. Maybe a superintelligence could, though you have to worry about some of the potential ways it might decide are the "best" (or shall I say "final") solution lol

[TechYogJosh]

Mainframe exists

There are public examples of mainframe exits by large enterprises. Therefore, it can happen for sure. Unlike earlier when MF exit was left to enterprises to figure out on their own and fight with IBM and CA, now deep pocket cloud vendors are after it. MF exit is not a technical problem but risk and mindset. That is the challenge tech vendors cannot solve for. They can do all underwriting of risks, but clients dont want underwriting, they dont want anything wrong to happen. They cannot believe nothing wrong will happen. In addition, IBM keeps bringing new metal and innovation to MF unlike other systems which are end of life and must be exited. But the exits will happen faster than what we think.