AWS Cloud Enterprise Strategy Blog

Yes, You Can Migrate Your Mainframe to the Cloud

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 : 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. 

***

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.

Mainframe Knowledge Curation

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:

Re-Hosting

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.

Mainframe Re-Host Migration to Cloud

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.

Mainframe Batch Job Migration to Cloud

Re-Engineering

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).

Mainframe Re-Engineering for Cloud

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.

Stephen Orban

Stephen Orban

Stephen is the GM (General Manager) of a new AWS service under development, and author of the book “Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT” https://amzn.to/ahead-in-the-cloud Stephen spent his first three-and-a-half years with Amazon as the Global Head of Enterprise Strategy, where he oversaw AWS’s enterprise go-to-market strategy, invented and built AWS’s Migration Acceleration Program (MAP), and helped executives from hundreds of the world’s largest companies envision, develop, and mature their IT operating model using the cloud. Stephen authored Ahead in the Cloud so customers might benefit from many of the best practices Stephen observed working with customers in this role. Prior to joining AWS, Stephen was the CIO of Dow Jones, where he introduced modern software development methodologies and reduced costs while implementing a cloud-first strategy. These transformational changes accelerated product development cycles and increased productivity across all lines of business, including The Wall Street Journal, MarketWatch.com, Dow Jones Newswires, and Factiva. Stephen also spent 11 years at Bloomberg LP, holding a variety of leadership positions across their equity and messaging platforms, before founding Bloomberg Sports in 2008, where he served as CTO. Stephen earned his bachelor’s degree in computer science from State University of New York College at Fredonia. https://www.linkedin.com/profile/view?id=4575032