5 ms·

Actual quote from a major insurance company CIO to me: "We've tried to migrate off the mainframe every few years for two decades. Every attempt has failed."

blackrock 6y ago
Why has it failed? Because of technology? Even building your own fault tolerant Linux cloud seems cheaper. Granted, an insurance company does not have the expertise to build massive computer operating systems. Or because of money, and other vendor lock-in’s? Then, with all the proprietary stuff, I can see how a migration can easily fail.
- dahfizz 6y ago
  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.
- freedomben 6y ago
  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.
- zerkten 6y ago
  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.
- bronson 6y ago
  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.
  - blackrock 6y ago
    Good to know. This provides job security for the CIO. If this project is canceled, then just jump ship, join another company, and do the same thing all over again.
bronson 6y ago
Same with a major retailer I worked for. They recently succeeded... by moving to a mainframe emulator in the cloud. The crusty batch software written in the early 80s is still running unchanged.
- curiousllama 6y ago
  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.
xphilter 6y ago
I wonder how many times they try hiring consultants to do it for them. I tried consulting and it was mostly bs. I imagine if they hired good people internally they could do it. (But finding good people I probably the biggest problem...)
lmilcin 6y ago
In my experience this is because of old and entrenched organizations built around mainframes. If you have a mainframe it is very likely to be supported by a small army of people who are not at all very happy to be replaced but at the same time are the only ones who knows how the stuff works and the stuff is very opaque to general developer population.

blackrock 6y ago

Why has it failed? Because of technology? Even building your own fault tolerant Linux cloud seems cheaper. Granted, an insurance company does not have the expertise to build massive computer operating systems. Or because of money, and other vendor lock-in’s? Then, with all the proprietary stuff, I can see how a migration can easily fail.

dahfizz 6y ago
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.
freedomben 6y ago
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.
zerkten 6y ago
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.
bronson 6y ago
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.
- blackrock 6y ago
  Good to know. This provides job security for the CIO. If this project is canceled, then just jump ship, join another company, and do the same thing all over again.

bronson 6y ago

Same with a major retailer I worked for. They recently succeeded... by moving to a mainframe emulator in the cloud. The crusty batch software written in the early 80s is still running unchanged.

curiousllama 6y ago
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.

xphilter 6y ago

I wonder how many times they try hiring consultants to do it for them. I tried consulting and it was mostly bs. I imagine if they hired good people internally they could do it. (But finding good people I probably the biggest problem...)

lmilcin 6y ago

In my experience this is because of old and entrenched organizations built around mainframes. If you have a mainframe it is very likely to be supported by a small army of people who are not at all very happy to be replaced but at the same time are the only ones who knows how the stuff works and the stuff is very opaque to general developer population.