It's usually because the software accrues warts, procedures, and special cases that get baked into the company's very core. They're all different and all valuable. Replacing them requires someone who fundamentally understands why it's all screwed up before they can find a workable fix (Chesterton's Fence).

But that's boring, awful work. It takes zillions of meetings trying to pry information out of unwilling participants who just want to do their jobs. And Reports! Acres of impenetrable reports trying to document what you found.

Nah, it's more fun for consultancies to roll in and rewrite everything, and then send every department through crazy change management. Suddenly there's a showstopper that nobody noticed until now, the project is already millions of dollars over budget and years late, so it craters.

A few years later another CIO does it all over again.

One reason these types of projects fail is that they are asking the people running the system today to do the migration and put themselves out of jobs. It's rare for people at the individual level to deny there is better tech, but as a group they know their situation. This was the same for migrations of ancient eRoom deployments to SharePoint in the mid-2000s. It's a pattern of working in big organizations.

The way many do this type of migration is to bring in another set of people (or outsource the system.) These new people have no attachment to the old system, but you lose the knowledge of the people you are replacing. This ends up being worse a lot of the time, but if it's too late then the organization won't rollback, and just spend a lot of time fixing their mistakes.

It's rare to get partnerships on the level that is required to change these big systems. In smaller projects, I've had the pleasure of working with some old-timers to update their technology, but it needs to be a collaborative effort.

There are a variety of reasons that I've heard. For some they simply can't match the level of performance of COBOL on the main frame. For others the code is so complex that re-implementing it with feature parity is nearly impossible. It took decades to get to where it is, it won't be replaced overnight.

Another fascinating explanation I heard about was the way floats and numbers are represented in the different architectures. Due to minor differences, a non mainframe/non COBOL implementation produces incorrect results.

I read a great article about it a year or so ago, I'll see if I can find it and link to it.

Mainframe applications are very different from "regular" Linux server applications. Migrating would almost certainly mean a complete redesign and rewrite of existing software. For industries where stability is paramount (banking, hospitals) it just isn't worth it.

Keep in mind that the applications running on these mainframes were written in COBOL 30+ years ago, often with poor documentation and specification. It is a tremendous task to port something like that and have the new system behave 100% like the old system.

I would love to hear about a study on the longest continuously-running pieces of enterprise software. I bet there's code in production written closer to the invention of flight than to today.