Heirloom Computing

Mainframe Migration? Why?

This article investigates why organizations should consider Mainframe Migration, the migration options they have, and the steps they need to take to transform their mainframe workloads to run on the cloud.

Let’s set the scene a little bit for a typical large organization that runs business-critical applications on the mainframe.

1. Your mainframe and your mainframe applications just run.
2. It causes no heartache, no troubles; when was the last time it “went down”?
3. If it weren’t for the pesky leasing payments and the endless contract renewal discussions, you probably wouldn’t give it too much thought.

But there are a few vague, uneasy feelings:

1. Perhaps you are not as responsive to your customers’ requirements as you could be.
2. At month-end, quarter-end, and year-end, the batch jobs are only just completed within the batch window.
3. There are a lot of grey beards in the PL/1, COBOL teams
4. Adding a new type of customer contract takes months with the mainframe screens and seemingly minutes with the web team.
5. Let’s face it a green screen does not have the possibility to represent data that a modern web browser supports

Would you rather be working with this green screen? A COBOL/CICS application that has been deployed to Pivotal Cloud Foundry using Heirloom.

Or with this Angular and D3 application that is also running on Pivotal Cloud Foundry and using exactly the same back-end COBOL/CICS program to run the amortization calculation?

Your company’s “front-end” applications are being delivered using industry best practices, continuous integration, and continuous deployment, CI/CD of the applications is de rigueur, and perhaps most importantly, your customers are extremely happy with the features, the responsiveness, and the look and feel. These applications and the teams that create them are agile in a way that the Mainframe group is not.

At the same time, these web applications are now capable of the same reliability as your mainframe environment, not because every single component works all the time but because every component has fail-over redundancy built-in. It is a different reliability model but one to which the organization is gradually becoming accustomed.

Your company is also becoming accustomed to hardware costs for running the non-mainframe applications to actually fall each year and yet still eke out higher and higher performance. Need to have a little performance kick for black Friday? Just automatically scale out some more application instances, and pay for the extra throughput performance ONLY when it is needed.

So now the scene is set, check back here for the next post, where I will lay out various Mainframe Migration options and the pros and cons of each one.