In-Depth Strategies from Infosys to Help Customers Re-Platform Mainframes on AWS

By Scott Kellish, Partner Solutions Architect at AWS
By Jaydip Sanyal, Associate Vice President at Infosys Ltd
By Ajay Jeswani, Ramanath Nayak, Keshar Jain, and Swapnil Jathar, Technical Architects at Infosys Ltd

Re-platforming is a popular mainframe modernization approach because it’s flexible. Migrating to the target environment is transparent to the user and does not mandate any changes to user interface, communication protocols, or business functionality.

Re-platforming is simpler than re-architecting, re-engineering, or manually rewriting, albeit with its own complexities. Like any re-engineering project, mainframe re-platforming includes critical phases such as assessing application inventory, migrating, and testing the application.

However, re-platforming migrates the application in a completely different way. Instead of a complete manual rewrite of the application, re-platforming adapts and recompiles all the mainframe COBOL and PL/I objects.

The recompiling performed during a re-platforming provides functional equivalence, reduces risk and cost, and saves critical time. Re-platforming also remediates unsupported code written in languages such as Easytrieve, Assembler, and others. Hence, it’s the fastest way to migrate applications to an x86-64-based cloud infrastructure.

Infosys is an AWS Partner Network (APN) Premier Consulting Partner and Managed Service Provider (MSP). Infosys has also earned the AWS Migration Competency, among several other Competency designations.

In this post, we discuss the phased migration approach Infosys uses for re-platforming mainframe applications. We’ll provide an overview of each step and the corresponding Infosys tools and accelerators we use to ensure successful mainframe migrations, including Micro Focus Enterprise Server (MF-ES).

Infosys has a great deal of experience using MF-ES, an emulation solution, to expedite and lower the cost of migrating mainframe applications to Amazon Web Services (AWS). MF-ES provides an application deployment environment on MS Windows or Linux for IBM Z mainframe, COBOL, and PL/I applications running on the IBM z/OS operating system.

Infosys Mainframe Re-Platforming Architecture

The following diagram depicts Infosys’s re-platformed AWS Cloud mainframe deployment architecture.

Figure 1 – Re-platforming environments using MF-ES for the AWS Cloud.

To begin with, we selected AWS managed services because they help reduce operating cost and complexity for customers.

Since we are going to deploy the mainframe applications we re-platform on MF-ES, we install MF-ES on one or more Amazon Elastic Compute Cloud (Amazon EC2) instances. The number and size of the MF-ES instances we’ll need for a given mainframe application depends on the application loading and usage patterns we find during the discovery and planning phases.

We store relational (SQL) data on either Amazon Relational Database Service (Amazon RDS) or Amazon Aurora, depending on the target database. Factors that affect the choice of target database are application parameters like VSAM usage, throughput, number of CRUD operations, and number of complex queries present in an application.

For applications with high Virtual Storage Access Methom (VSAM) usage, MF-ES v5 release supports routing I/O requests to a relational database management system (RDBMS), in particular Amazon Aurora, to take advantage of its high availability and better performance characteristics. Similarly, applications with lots of IBM Db2 database access could be a good candidate for Amazon RDS.

In the past, Infosys has stored VSAM files on disk using Amazon Elastic Block Store (Amazon EBS). VSAM is a file storage access method used in mainframes. Amazon EBS is a high-performance block storage service suited to a broad range of workloads. It’s particularly suited to workloads with throughput and transaction-intensive workloads traditionally hosted on mainframes.

Use the MF-ES AWS Quick Start to Accelerate Re-Platforming

Re-platformed mainframe applications can leverage numerous AWS services such as access management, monitoring, logging, and scheduling. For guidance in leveraging these AWS services, Micro Focus offers an AWS Quick Start for deploying Enterprise Server on AWS. It provides a reference architecture for deploying MF-ES on AWS.

The Quick Start guide deploys an MF-ES environment that follows Micro Focus and AWS Well-Architected best practices for building secure, high-performing, resilient, and efficient infrastructure for cloud applications. Using the MF-ES AWS Quick Start, you can deploy a secure, well-architected trial environment in under one hour.

The Quick Start guide includes AWS CloudFormation templates, which let you model and provision all the resources needed for an application across all regions and accounts. They help you tailor the reference architecture to meet a customer’s specific requirements. This approach can accelerate a re-platforming project after a successful trial evaluation.

Infosys Re-Platforming Methodology

The Infosys Legacy Modernization Practice has delivered more than 100 modernization projects over the last 10 years, many of which involve re-platforming. During that time, Infosys has learned that re-platforming mainframe applications to an x86-64 cloud infrastructure requires a methodical approach, so we designed and implemented an end-to-end methodology and custom tools.

One of the capabilities leveraged for these engagements is the Infosys Knowledge Curation Platform – Ki. The Ki platform acts as the knowledge repository for all the experience Infosys has garnered from its modernization projects. Infosys has used Ki extensively to support decision makers in choosing their optimal modernization strategy.

The following sections explore the Ki-based methodology and tools:

1. Assessing the applications and their mainframe environment.
2. Developing a migration strategy and pre-planning.
3. Migrating the applications.
4. Day One — Cutover.
5. Day Two — Monitoring and Maintenance.
6. Post-deployment activities.

1. Assessing the Applications and their Mainframe Environment

We begin every re-platforming engagement with an assessment of the existing mainframe application and environment. This is a critical phase of the re-platforming journey, in which we determine the roadmap and cost of the re-platforming approach according to the following parameters.

Application Assessment

It’s critical we map each mainframe application component to its corresponding cloud service, so this assessment gives us a complete picture of the current application landscape.

To begin, we determine the effort, complexity, and feasibility of migrating each mainframe application and data asset. We then develop an architecture diagram of the application in the target system, based on insights from Infosys tools. These insights help determine the number of MF-ES instances and regions required in the AWS environment.

Often, components like Assembler, Easytrieve, and REXX in the mainframe architecture may not be supported in the MF-ES environment. These unsupported components will require a risk mitigation plan.

Infosys also provides a purpose-built ROI calculator for a high-level overview of the savings expected after migration.

Application Interdependencies

Interdependencies between applications can affect the complexity of a migration. Infosys Dependency Analyzer highlights all of the interfaces and data flow between applications as a way of identifying potential issues during migration.

Application Language Distribution

MF-ES supports some of the common programming languages used on mainframes. If a mainframe application is written in a language Infosys doesn’t support, Ki helps determine how much remediation that application needs. Ki enumerates all the unsupported components in detail, making it easier to assess the magnitude of the changes needed.

Active – Inactive Directory

Based on our experience, we find that 17-40 percent of a mainframe application’s source code is often unused. Once identified, this inactive code does not require additional analysis, as it will not be migrated. Infosys SMF Log Analyzer helps segregate active and inactive code inventory to save cost and time.

Environment Details

Details about the mainframe environment help size the AWS architecture. Infosys SMF Log Analyzer, used together with the Ki platform, can generate meaningful insights such as:

• MIPS consumed by the development, test, and production environments that help in sizing the AWS environment.
• Batch window completion time to be matched with that on the AWS environment.

Database Size and Complexity

We use Infosys Data Migration Service Suite (iDSS) to arrive at the number and type of database objects, the size of the data to be migrated, and the time required to perform the migration.

Peripherals and Interfaces

To plan the migration, we need a detailed assessment of peripheral jobs such as interfaces to printers. We have to tackle interfaces like FTP, MQ, and others in a strategic way so the business flow is not affected.

Performance Requirements

It’s important to assess the current performance of the applications on the mainframe to make sure we provide the same or better performance in AWS.

2. Developing a Migration Strategy and Pre-Planning

In this phase, we develop a detailed migration roadmap that documents the target state to be achieved, along with timelines and estimates. It includes steps such as:

• Creating proofs of concept (PoC) for the migration of any concerning aspect.
• Defining the infrastructure needed to build the target environment.
• Starting the process to procure software licenses for MF-ES and other tools.
• Creating a detailed action plan to mitigate external and internal application dependencies.

A properly developed and comprehensive project management plan is critical to the success of the migration. Implementations typically follow either a one-step approach or phased approach. Each has its own advantages and disadvantages, as detailed below.

Purpose-built tools from Infosys can help recommend the appropriate approach based on a client’s specific environment.

One-Step Approach

Pros:

• No additional cost and no risk of building bridges between migrated applications and residual applications on the mainframe.
• Project timelines will be relatively short, whereby Infosys meets mainframe exit timelines.

Cons:

• Clients do not have access to any Minimum Viable Product (MVP) until implementation.
• There is a risk of longer timelines if the solution fails.

Phased Approach

Pros:

• Clients can obtain a live MVP during the early stages.
• In case of failures, solution risk is addressed during the early stages of the migration cycle.

Cons:

• Additional interface and data transformation scripts need to be built for communication between mainframe apps and migrated apps. Building additional interfaces comes at added cost and risk.
• Project timelines will be relatively longer due to multiple releases.

3. Migrating the Applications

In this phase, we leverage the MF-ES AWS Quick Start to set up the target cloud infrastructure that hosts the migrated application. We rewrite any non-supported components in Micro Focus COBOL.

The main activities in this phase (explained in detail below) are:

• 3.1 Migrating the application source code
• 3.2 Migrating the application data
• 3.3 Testing the re-platformed application
• 3.4 Planning the application deployment

The following figure is a high-level timeline of the end-to-end process of application migration. This diagram is generic, and will be customized for the needs of each customer.

Figure 2 – Example of a high-level timeline for migration.

3.1 Migrating the Application Source Code

We usually need to modify the existing mainframe source code before it’s fit to run on the Micro Focus environment on AWS. For example, we may need to modify SQL statements, we must replace unsupported JCL utilities with their equivalent utilities, and we’ll need to modify interfaces to point to new FTP servers.

We have created scripts that can automate these changes during the code migration process.

Apart from the source code, we need to migrate the scheduler to the new scheduler software. We should also modify printer configurations to point to new hardware, and we have to migrate the source code change management tool to Git on AWS.

Each of these peripheral migrations require a detailed step-by-step approach. For instance, migrating the scheduler requires the following set of steps:

• Get the scheduler dump from the current scheduler.
• Standardize the scheduler dump to a common format using custom scripts. This common format is defined by Infosys to help migrate from the most common mainframe schedulers to target schedulers on cloud.
• The intermediate common format is then modified to suit the target scheduler through another set of custom scripts.
• Upload the modified scheduler dump to the target state.

We can take advantage of several utilities that run on the mainframe, such as SORT, XMIT, SMTP, and FTP. Most of these are present in the Job Control Language (JCL) with some embedded business logic, such as creating a PDF file and sending it as an email attachment.

For instances like this, we have a custom solution that can mitigate the problem with the least number of changes to the mainframe code. One example is the Infosys Email Suite that helps in sending emails. Some of its features include:

• SMTP statements that were present in mainframe jobs can be used as-is in the re-platformed application.
• Flexibility to dynamically generate files like PDF and CSV and send them as attachments via email.
• Logging of all email activities in an application.
• Email body can be populated from a file in MF-ES.

3.2 Migrating the Application Data

Data migration, which involves migrating both databases and files, is a critical activity for the success of the migration. Infosys provides several tools to ensure we migrate data without failures.

Infosys Rehosting Suite, a collection of other suites and tools, provides a unique way of ensuring minimum errors during migration. One of the tools in the suite, Infosys File Migration Suite, can automate up to 90 percent of the effort required to migrate files from the source mainframe to the cloud.

This is possible through:

• Rich repository of file migration rules collected over previous projects.
• Tool-generated JCL statements for formatting and migrating a variety of datasets types, including variable block, fixed block, migrated, and non-migrated.

Infosys Database Migrator, another tool in the Infosys Rehosting Suite, helps create a standardized database schema. We also use it to create custom scripts to extract data and transfer files, copy them to the target environment, and load them into the target database.

Separate from the Infosys Rehosting Suite, Database Migrator can be used in re-engineering scenarios, as it also supports several non-mainframe databases.

We use these custom scripts and accelerators to migrate data according to the following process:

• We make a golden copy of the data/file in production to use in all the testing phases.
• We migrate the files in this way:
  • Identify the list of files under a high-level qualifier on the mainframe.
  • Use scripts to categorize files based on variable/fixed length, migrated/immigrated, tape/DASD, VSAM, GDG, or flat files.
  • Perform custom processing based on the type of file.
  • Create automated JCLs to extract the file data, use FTP to transfer it to AWS, and catalog it on AWS with zero errors.
  • Migrate tape files to DASD and then transfer them via FTP to AWS.

Migrating to DASD requires coordinating with system administrators to provision the required space on the mainframe. All of these aspects will be considered during the planning of cutover activities.

We migrate databases in this way:

• Depending on the business requirement, we can migrate data all at once or in phases. In either case, Infosys Data Service Suite (iDSS) is capable of migrating data and capturing change data to keep the target and mainframe architectures in sync during migration.
• We validate data through iDSS, which reports any errors that occurred during the data migration process.

3.3 Testing the Re-Platformed Application

Testing is a critical activity that must be carried out at multiple stages during the migration.

Infosys makes sure to perform these tests on every migration:

• Unit testing: Once the source code is standardized for MF-ES, we run jobs on the target state to make sure they are running as expected and producing the right results.
• System integration testing: We identify the critical business workflows and run them on the AWS environment to ensure the end-to-end business functions are working as expected.
• Parallel testing: We perform parallel testing between the MF-ES environment and the mainframe environment, using tools such as Infosys LegMap suite.
• Performance testing: Some jobs may not perform as well on AWS as they did on the mainframe. Sometimes the cause is incorrect use of utilities such SORT, UNLOAD jobs, and IDCAMS, that slow down performance in the MF-ES environment. We tackle these performance bottlenecks on a case-by-case basis.

3.4 Planning the Application Deployment

Deployment is a crucial activity that determines the success of the whole modernization effort. Before we deploy the re-platformed application into production, we make sure we have clearly spelled out:

• Our deployment strategy.
• Pre-cutover activities.

Deployment Strategy

These characteristics influence the deployment strategy we develop:

• Application size: Depending on the size of the application derived from Infosys SMF Log Analyzer, we choose either a one-step migration approach or phased migration approach.
• Data size: The larger the volume of data, the longer it takes to move it from the mainframe to the AWS environment. We leverage decision parameters such as the number of threads needed, retry mechanisms, and others, that are built into our tools. These parameters help scope the volume of data so we can define the right data migration strategy.
• Interfaces/peripherals used: Defining a strategy to re-route interfaces to the AWS infrastructure will help cut downtime for both downstream and upstream systems. It’s also critical that we configure peripherals such as printers and the SMTP email server.
• Authorization and authentication: We migrate the existing IBM RACF security design to a new or existing Active Directory or LDAP solution using a tool-based approach. We must execute this step carefully to ensure that the overall security requirements of the application environment are met.

Pre-Cutover Activities

Before we cutover, we merge any code that has been changed by the application maintenance team during the migration. Before the final cutover happens, we perform some prerequisite activities, such as freezing the target environment source code, creating a software deployment package, and migrating it to a staging area in the target environment.

After we complete these prerequisites, the migration team accepts no further code changes.

4. Day One – Cutover

This is the crucial day when the MF-ES production environment goes live and the mainframe application becomes secondary, acting only as a stand-by. These are the activities we perform during cutover.

Environment Cutover

We change the IP addresses and reconfigure the DNS entries, particularly for interfaces and peripherals that need to point to the AWS environment.

Delta Data

If the mainframe environment was still being used for production, we now freeze it to prevent any further use. If any files and database data changed since the last replication, we move them using Infosys data tools in a multi-threaded fashion, as these activities are time-critical.

We use Infosys Comparator to quickly validate the final AWS environment dataset.

Validation

Once the application, its data, and configuration are established in the AWS target environment, we perform several validations. This includes online and batch application validation, external transactions, and inbound and outbound files/transaction sanity testing.

We also validate the infrastructure, including verifying all IP connectivity, access provisioning, and server and network performance

5. Day Two – Monitoring and Maintenance

Once users are successfully using the application on AWS instead of the mainframe, we carry out these activities to make sure the re-platformed application is performing as it should.

Monitoring and Alerting

Mechanisms for proper monitoring, alerting and, if possible, automatic remediation, are critical to successfully meet SLAs. Based on Infosys’s experience with MF-ES and AWS, we recommend and implement monitoring and alerting appropriate for each client’s environment.

This can include:

• Extending existing infrastructure monitoring and alerting capabilities built into the MF-ES AWS Quick Start guide.
• Using Infosys Email Suite, along with custom scripts, to monitor MF-ES runtimes and send alert messages for issues detected at the application level.
• If the application is running in parallel mode, the Infosys Comparator tool can help identify and alert users on the differences between application runs.

Housekeeping and Logging

Logs written by MF-ES can pile up over time. The Infosys Log Archiver utility can help move critical logs to cheaper secondary storage on AWS.

While the MF-ES AWS Quick Start recommends moving operating system-level logs off instance to AWS CloudWatch Logs, we can easily adapt this approach to work with Infosys Log Archiver to provide a single, cohesive log archiving solution.

Backup and Recovery

Backup and recovery are important to business continuity. An Amazon Machine Image (AMI) provides the information required to launch an instance.

An AMI can take a snapshot of a virtual machine at regular intervals. You can use this snapshot to restore the instance in real time whenever recovery is needed.

Chargeback and Billing Reporting

AWS is transparent about billing and chargebacks, providing a detailed Billing Report (DBR) and Cost and Usage Reports. These contain the most comprehensive set of cost and usage data available.

The reports also help you drill down into exactly how much you spent on each AWS service.

Continuous Integration/Continuous Delivery (CI/CD)

Services such as AWS CodeCommit and AWS CodeDeploy deliver a seamless developer experience from creating a CI/CD pipeline to deploying flexible DevOps operations.

• AWS CodeCommit hosts secure Git-based repositories. It eliminates the need for developers to operate their own source control system or worry about scaling its infrastructure.
• AWS CodeDeploy automates software deployments to a variety of compute services such as Amazon EC2, AWS Fargate, AWS Lambda, and your on-premises servers. Developers can use AWS CodeDeploy to automate software deployments, eliminating the need for error-prone manual operations.

Source Code Management

Using AWS CodeCommit, you can create highly scalable private Git instances for complete source code management.

Security Management

Built-in AWS tools offer 360-degree security management with features like infrastructure protection, data protection, identity and access management (IAM), and compliance.

6. Post-Deployment

Once the application is stable on AWS, we usually provide guidance and support regarding best practices for decommissioning the source mainframe application. This support includes critical data archival and the overall decommissioning of the mainframe itself.

Types of Re-Platforming Customers

The following table provides a cross-section of the customers that have benefited from Infosys’s re-platforming efforts.

Figure 3 – Cross-section of Infosys re-platforming engagements.

Conclusion

Re-platforming a critical mainframe workload can be a complex operation. MF-ES 5.0 has cutting-edge features that deliver cloud elasticity for mainframe applications along with the security, reliability, scalability, and flexibility of AWS.

Infosys has collaborated with Micro Focus and AWS to create a methodology that helps clients migrate their mainframes to AWS using MF-ES.

Besides leveraging significant expertise in mainframe re-platforming, Infosys also provides trained talent and a host of tools and accelerators for faster, efficient, and secure migrations.

Learn more about MF-ES on AWS Cloud in Empowering Enterprise Mainframe Workloads on AWS with Micro Focus.

For more information on how Infosys adds value to Micro Focus mainframe re-platforming solutions, download the whitepaper: Infosys Mainframe Modernization Assessment Powered by Micro Focus Enterprise Analyzer. You may also contact the Infosys Legacy Modernization team at LegacyMod@infosys.com.

.

.

Infosys – APN Partner Spotlight

Infosys is an APN Premier Consulting Partner and Managed Service Provider. Infosys helps enterprises transform through strategic consulting, operational leadership, and co-creation of breakthrough solutions in mobility, sustainability, big data, and cloud computing.

Contact Infosys | Practice Overview

*Already worked with Infosys? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.