By Pavel Vasilyev, VP of Technology – ClearScale
By Jason Tasker, Principal Architect – ClearScale 

ClearScale-AWS-Partners-1
ClearScale
Connect with ClearScale-1

Every mainframe modernization and migration project is unique, with its own objectives, business requirements, and challenges.

However, most projects can be successfully accomplished using resources from Amazon Web Services (AWS) and some variation of the following 10-step process:

  1. AWS research
  2. Information gathering
  3. Discovery
  4. Pattern and tool selection
  5. Design and architecture
  6. Proof of concept (PoC)
  7. Migration/modernization planning
  8. Migration/modernization execution
  9. Testing
  10. Go live

Many of the tasks associated with each step often segue into other steps. Some are conducted concurrently with tasks in the other steps. Others are revisited in subsequent steps.

Employing an agile approach and mindset throughout the process can help project teams maintain the flexibility to pivot and adapt as needed to ensure project success.

In our roles at ClearScale, we have been the Solution Architects for several mainframe and modernization projects for some of our biggest customers.

In this post, we’ll detail the 10 steps that ClearScale relies on to complete these complex projects and provide tips to help you successfully complete similar projects.

ClearScale is an AWS Premier Tier Services Partner that combines technical depth and expertise to build tailored cloud solutions that help you innovate, improve operational efficiency, and increase business agility.

Step 1: AWS Research

If you’ve decided to use AWS for your mainframe modernization and migration project, the first thing to do is to become acquainted with the resources AWS offers.

The primary resource is the AWS Migration Acceleration Program (MAP) for Mainframe, featuring processes, tools, and services to simplify cloud migration projects.

AWS also offers mainframe-to-AWS best practices, gleaned from the experience of past projects, customers, and AWS Partners, which include:

  • Complex proof of concept.
  • Maximum automation.
  • Decide pattern, then tool, then architecture, then activities.
  • Vendor-neutral pattern selection.
  • Systems integrators selection.
  • Modernize legacy data stores.
  • Workload-based modernization.
  • Serialize technical, then business-level modernizations.
  • Define tool evaluation factors.
  • Estimate modernization and runtime costs.

In addition, AWS provides successful patterns implemented by AWS customers, such as short-term migration with automated refactoring or emulator rehosting, and augmentation with data analytics or new channels.

Perusing the various AWS blogs and customer stories will also help provide a good understanding of what AWS offers and how those resources can facilitate mainframe modernization and migration projects.

Step 2: Information Gathering

The information gathering phase establishes both the foundation and framework for the project. It’s here that we determine—and confirm—the business and technical requirements, as well as the overall project objectives.

Is the goal to reduce complexity and/or costs? Is it to take advantage of the benefits associated with a cloud environment? Is it to increase agility or adapt to new trends? Is it to transition from batch processing to real-time processing? Is it to free up IT department resources for higher-level issues?

Is there a desired or required schedule that must be met? If downtime or other disruptions were to occur, could the business continue operations?

It’s essential to get input from all relevant stakeholders at this stage, and to communicate the findings. This helps set realistic expectations for the end results, as well as provide guidance for the remaining steps.

This is also the stage where you should bring in AWS MAP for Mainframe. Designed to spur project success by using AWS services, best practices, tools, and incentives, MAP for Mainframe entails a three-step approach: assess your readiness, mobilize your resources, and migrate or modernize your workloads.

It’s the first step—assess your readiness—that is most important during the information gathering stage. It includes a migration readiness assessment to help identify gaps and required capabilities along the six dimensions of the AWS Cloud Adoption Framework (AWS CAF)—business, process, people, platform, operations, and security.

On the financial front, it can help you build a total cost of ownership (TCO) model for the project. It also includes an optimization and licensing assessment with recommendations for optimizing licenses on AWS.

In terms of people and process, one of the most critical tasks to include in this initial stage is ensuring the project team can and will employ agile and DevOps methodologies throughout the project.

This is critical for accelerating the software development process and velocity for quicker time-to-market. It also helps with using integrated development environments (IDEs) to increase code development efficiency and facilitates the onboarding of new developers and skilled talents.

IDEs contrast with legacy mainframe development, which can still use outdated terminal emulation, text interfaces, function keys, and column requirements, along with peculiar dataset, job, and spool concepts.

Step 3: Discovery

This is where you determine what you’ll be working with and identify potential challenges or needs that may influence the later phases.

Start by cataloging and documenting all applications, languages, databases, networks, platforms, and processes in your environment. Document the interrelationships between applications and all external integration points. Use automated analysis as much as possible. Feed everything into a central repository.

You’ll use information from this stage to assess the compatibility of the data sources and applications with the target architecture that will be created, along with the integration points to ensure a smooth migration.

Qualitative and quantitative analysis performed on source data will also help guide selection of the right tools and migration activities in subsequent steps.

Next, establish ownership for delivery of each of the components listed below. There may be others, depending on your environment. Obtain commitments for delivering the required information, including:

  • Primary programming languages.
  • Secondary programming languages.
  • Batch application infrastructure.
  • Data infrastructure and data stored in files and relational databases.
  • Online application infrastructure.
  • Development, test, and quality assurance (QA) infrastructure.
  • Production, failover, and disaster recovery (DR) infrastructure.
  • Application inventory, along with business functionality of applications and how applications are accessed.
  • Application and system-level security.
  • Output, content, and report management.
  • Other systems that are dependent on the mainframe.

Step 4: Pattern and Tool Selection

Pattern and tool selection often coincide with modernization and migration planning (Step 7) and is also integral to design and architecture (Step 5), as well as proof of concept (Step 6).

There are a variety of patterns available, and the one selected will frame the overall approach (see Step 7) and guide the selection of tools.

The tools selected must be technically tested with a complex PoC as early as possible. Once the tool is validated, the overall architecture is created based on the tools and AWS best practices. The technical architecture then drives the modernization implementation activities.

Step 5: Design and Architecture

This is where the solution gets built out, including the cloud environment, transaction loads, batch requirements, programming language conversions and replacements, integration with external systems, and any third-party software requirements, as well as accommodations for future requirements.

Pay extra attention to performance. What does the DevOps pipeline look like? How might containerization affect modernization tactics? What is the support ecosystem for the target environment?

In general, the design should include:

  • AWS instance details: This includes those for pre-production, production, and performance environments, as well as the development, test, and integration environments.
  • Batch requirements: Most mainframes run I/O-intensive batch applications that require low latency from storage or data stores. Make sure to design and test for distributed systems.
  • Integration with external systems: Mainframes are commonly the back end for satellite or partner systems, so their integration must be retained after migration. This includes protocols, interfaces, latency, bandwidth, and more.
  • Programming language conversions and replacements: Some languages may not be supported or available on the target components but can be converted with tools or replaced by newer functions.
  • Third-party software requirements: Each independent software vendor (ISV) may not have a functionally equivalent software on AWS and will require a specific migration path definition.
  • Transaction loads: Non-functional requirements in general, performance requirements, such as high transactions per second or quick response times, are often critical for mainframe workloads execution. This implies careful design and sizing of the underlying network, storage, and computing.
  • Planning for future requirements: Business and IT strategies and priorities drive architecture decisions, especially for future performance and integration capabilities.
  • Source code: This may include MAPPER, LINC, COBOL, or Batch Control Language. Data stores may include networked, hierarchical, relational, or file-based data stores.

Step 6: Proof of Concept

Projects can fail when selected tools and the proposed architecture don’t address the most complex technical aspects of a mainframe workload.

A PoC should be run using customer-specific scenarios to ensure everything works as intended and achieves the required objectives. This allows for making modifications before committing to the actual migration.

Make sure to cover the complexities that can reside in customer mainframe workloads, such as those related to batch duration, numerous program and data dependencies, complicated logic, uncommon legacy technology or versions, latency requirements, high throughput or transactions per second, or large quantities of code or data.

Step 7: Migration/Modernization Planning

Develop a plan to guide all aspects of the migration/modernization. It should define roles and responsibilities and include a schedule that also accounts for any downtime or business disruptions. It should also cover testing (go with automated testing if possible), backup and DR, communication, and other components.

The plan should also be tailored to your specific modernization/migration strategy:

  • Retire: Retire the application that is no longer required. Archive data in the cloud for regulatory compliance.
  • Retain: Retain some of the existing mainframe capabilities and remediate or amend any specific pain points.
  • Replace: Replace with a combination of COTS (commercial-off-the-shelf) or SaaS (software-as-a-service). Migrate data to cloud infrastructure.
  • Rehost: Rehost to another less expensive location to gain cost benefits without carrying the risk resulting from programming language changes.
  • Re-platform: Migrate to new platform/operating system infrastructure with minimal changes to code/programming languages.
  • Refactor: Restructure existing code or programming language to a modern one to reduce the risk of technical debt and several skill risks. You can exploit new capabilities from modern operating systems easily.
  • Re-architect: Reimagine your business agility and performance by exploiting the new cloud computing features. Use domain-driven designs to rewrite your applications based on new requirements. This lets you not establish your application on current and future needs, allowing you to modernize your technology and obsolete business processes.

Depending on the strategy employed, any number of tools to accelerate the associated tasks can be employed. For example, tools can be used to automate code refactoring and to automate testing.

Keep in mind that not all applications will, can, or should be moved. Depending on your situation, you may need to use a staged migration. Some applications will be moved first, while others remain on the mainframe temporarily or permanently.

This approach typically requires systems that allow applications and databases to interoperate between the mainframe and AWS.

Step 8: Migrate/Modernize Execution

This is where the real action takes place—transferring the data and applications according to the plan outlined in Step 7.

Many deployment activities can be initiated in parallel with earlier tasks such as creating and configuring AWS instances, migrating static data, and other infrastructure or framework activities.

Constant communication is critical to ensure the plan is followed, and the team can immediately deal with any issues that arise.

Step 9: Test

Testing is constantly conducted that, among other things, checks for:

  • Integration
  • Data accesses
  • Code modifications to accommodate data type changes
  • Newly-developed code

Make sure your technical team has been trained in problem resolution processes and procedures before going into production. Understand your vendor’s resolution and bug tracking process. Be sure their process is in alignment with yours. This is important for reducing the time it takes to understand and resolve issues.

As noted earlier, consider using automated testing solutions designed for the mainframe. This can help automate the preparation of test data and scripts, while leveraging existing testing assets and processes that may be appropriate.

If any issues or anomalies arise during the testing, don’t move ahead until everything has been resolved.

Step 10: Go Live

Once the new environment is live, check in with all stakeholders and users to ensure things are working.

Document and evaluate the lessons learned. Continue to assess the effectiveness of the environment in meeting the project’s objectives.

Summary

This post provides a high-level look at the mainframe-to-AWS modernization and migration process. Remember, there are many intricacies, exceptions, and potential obstacles that may come into play. The key is to be as prepared and informed as possible and, most importantly, be able to adapt.

ClearScale has extensive experience migrating and modernizing mainframes on AWS. Learn how AWS and ClearScale can help with your mainframe migration project by contacting [email protected].

The content and opinions in this blog are those of the third-party author and AWS is not responsible for the content or accuracy of this post.

.
ClearScale-APN-Blog-Connect-1
.


ClearScale – AWS Partner Spotlight

ClearScale is an AWS Premier Tier Services Partner that combines technical depth and expertise to build tailored cloud solutions that help you innovate, improve operational efficiency, and increase business agility.

Contact ClearScale | Partner Overview

*Already worked with ClearScale? Rate the Partner

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