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.
But there are a few vague, uneasy feelings:
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.