For many large and well tenured enterprises, the mainframe is often cited as a central point of gravity that stalls or elongates a large cloud migration. Many enterprises feel that they have few people who have the domain and technology expertise to execute a mainframe migration, and those who are still working on the mainframe can be harder to motivate for a cloud migration (though I do believe You Already Have the People You Need to Succeed with Cloud). While there is no silver bullet to magically lift-and-shift and modernize your mainframe applications as you migrate it to the cloud, there are reasonable approaches leveraging various migration strategies. To explain, I’ll turn it over to AWS’ Erik Farr, who has spent much of the last year working with Infosys on an AWS mainframe modernization practice.
(Note: Note: Since this blog was published, we have seen a significant increase in mainframe workloads migrating to AWS. Phil de Valence and Erik Farr have laid out what we’ve learned in their new blog: Yes, You Should Modernize Your Mainframe with the Cloud. This is a must-read for anyone considering modernizing their Mainframe using the AWS cloud and helps drive home the concepts originally discussed in this blog. These best practices, and a number of others, are now available in my book Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT).
In the most recent series of blogs that Stephen published on mass migrations, he often talks about a spectrum of complexity for workloads that are being migrated to the cloud. In this spectrum, he puts virtualized, service-oriented architecture workloads at the low end and monolithic mainframes at the high end of complexity, and for good reason. Mainframes have often been with organizations for decades and are usually running mission critical workloads that have specific performance and security requirements that ensure smooth business operations. When talking with customers about their overall IT landscape and cloud migration strategy, it’s easy to skim past the mainframe workloads and put them into the “revisit” bucket for a future date. However, for companies that have a compelling event to get off their mainframe, or are starting to revisit their landscape, the time is now for a mainframe migration.
I have been fortunate enough to get a deeper understanding of common approaches to mainframe migrations to AWS during my time helping Infosys, an AWS premier partner, create their mainframe to AWS migration solution. They have been a leader in managing, developing on, and modernizing mainframes for decades, and they are extending that experience into migrating mainframe workloads as a core competency. Using their Knowledge Curation platform (KI), they are able to analyze the customer mainframe code to understand exactly what’s running and what’s not.
The outputs of this process, which often takes less than six weeks, are then used to help the customer create a business case and ultimately a roadmap for the full mainframe migration project.
There are three main approaches to mainframe migrations that we see customers exploring — re-hosting of workloads, batch-job migration and full re-engineering. Each have their pros and cons and ultimately customers decide based on risk tolerance, business case and following their overall cloud strategy. Here is a quick breakdown of these migration approaches:
A re-hosting solution runs existing mainframe applications on an x86–64 based Amazon EC2 instance using a mainframe emulator (i.e. Micro Focus Enterprise Server, TMaxSoft OpenFrame, Oracle Tuxedo ART). This migration is seamless from an end-user perspective and it does not require changes to standard mainframe technologies like 3270 Screens Web Cobol, JCL and DB2. There is often a bit of re-platforming in this approach as well, like moving older and difficult to maintain databases to newer RDMBS engines and hosting on Amazon RDS.
Batch Job Migration
Batch jobs often form a large portion of the mainframe application portfolio and while some are business-critical, usually a significant number of these jobs are of low business value and consume a large amount of MIPS. Whether they are file based or near real-time processes, offloading the heavy-lifting to the AWS Cloud will enable customers gain additional insights to their data and reduce MIPS consumption on their existing mainframe.
The re-engineering approach is recommended when the existing mainframe application is no longer able to meet future-state business requirements or an agile target architecture. This approach will create a new application with similar performance and equal or enhanced functionality. Typically, this is done using cloud-native techniques, leveraging micro-services (i.e. Amazon API Gateway, AWS Lambda), Containers and Decoupling (i.e. Amazon EC2 Container Service, Docker containers, Amazon Simple Queueing Services) and Data Analytics, Artificial Intelligence and Machine Learning (i.e. Amazon EMR, Infosys Mana for AI, or Amazon Machine Learning).
Regardless of the approach taken, it’s important for companies to understand that mainframe workloads should be considered in their cloud migration strategy. This will often result in significant cost savings, increased agility and a future-proofed architecture. For more information on the topic of mainframe migration and how AWS and Infosys can help, please review the mainframe migration to AWS whitepaper my colleagues Sanjeet Sahay, Tom Laszewski and I co-authored with Infosys.