By Jason Tasker, Principal Architect, ClearScale
Every mainframe modernization and migration project is unique, with its own objectives, business requirements, challenges, and more. However, you can successfully accomplish most AWS mainframe migration projects using AWS resources and some variation of the following 10-step process:
- AWS research
- Information gathering
- Pattern and tool selection
- Design and architecture
- Proof of concept (POC)
- Migration/modernization planning
- Migration/modernization execution
- Go live
Many of the tasks associated with each step of the AWS mainframe migration process 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.
Step 1: AWS Mainframe Migration 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 Partner Network (APN) Partners, which include:
- Complex Proof of Concept (PoC)
- Maximum automation
- Decide pattern, then tool, then architecture, then activities
- Vendor-neutral pattern selection
- System 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 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 the 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? Or is it to increase agility or adapt to new trends? Is it to transition from batch processing to real-time processing? Perhaps the goal is to free up IT department resources for higher-level issues?
Do you need to meet a desired or required schedule? If downtime or other disruptions were to occur, could the business continue operations?
Get input from all relevant stakeholders at this stage. And communicate the findings. This helps set realistic expectations for the end results, as well as provide guidance for the remaining steps.
Migration Acceleration Program
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 – business, process, people, platform, operations, and security.
On the financial front, it can help you build a 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 (IDE) to increase code development efficiency and facilitates the onboarding of new developers and skilled talents. IDE contrasts 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 the selection of the right tools and migration activities in subsequent steps.
Next, establish ownership for the 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 QA infrastructure
- Production, failover, and disaster recovery infrastructure
- Application inventory, along with business functionality of applications
- 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 Step 7: Modernization and Migration planning and is also integral to Step 5: Design and Architecture and Step 6: Proof of Concept.
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. Revisit AWS’s mainframe modernization and migration best practices.
The tools selected must be technically tested with a complex proof of concept (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 you build the solution, 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 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 Architecture
Projects can fail when selected tools and the proposed architecture don’t address the most complex technical aspects of a mainframe workload. A proof of concept (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: AWS Mainframe 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 disaster recovery, communication, and other components.
The plan should also be tailored to your specific modernization/migration strategy:
- Retire – Retire applications that are 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. 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 a 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, you can use any number of tools to accelerate the associated tasks. For example, tools that automate code refactoring and testing.
Keep in mind that not all applications can or should be moved. Depending on your situation, you may need to use a staged migration. Some applications are 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: AWS Mainframe Migration / 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
Constantly conduct testing that, among other things, checks for:
- Data accesses
- Code modifications to accommodate data type changes
- Newly developed code
Make sure you train your technical team 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 is 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.
The Bottom Line of AWS Mainframe Migration
This is a high-level look at the mainframe-to-AWS cloud modernization/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.