How patterns can help you plan and implement a large-scale cloud migration

Many enterprises use frameworks such as “The 7 R’s” to formulate their migration strategy and approach when embarking on a large-scale cloud migration. These frameworks are great at conceptually capturing “how” to migrate applications (e.g., rehost vs. refactor), but they don’t take into account “what” the target state post-migration should look like or help you plan your journey towards that target state. Your journey will include building a cloud platform, developing new operating capabilities and growing the skills of your teams – in parallel to moving your applications to the cloud. In this post, we explain how a migration patterns framework can support you in your holistic migration journey.

We wanted to incorporate a customer perspective directly into this post. So we asked Alex Lopes, the Global Head of Infrastructure and Security Architecture at Zurich Insurance, to provide his perspective.

Overcoming the challenges of large-scale cloud migrations

Many customers want to migrate their applications to AWS. Large-scale migrations of hundreds or thousands of applications can turn into complex transformation programs in a short timeframe. This is especially true if you aspire to modernize your application estate as part of the migration and not “lift-and-shift” your virtual machines (VM) into the cloud.

Modernizing enhances your applications to gain more agility, scalability, and resilience. You will typically use a broader range of AWS services to run your applications. You must build a cloud platform to support these services in a compliant manner, adjust your operations, and evolve the skills across your organization. One key challenge of a large-scale cloud migration is determining the right amount of modernization you want to target. It must align with your strategic objectives, and the budget and timeline of your migration program. Another common challenge is creating a migration plan, which will ensure that your program continuously delivers business value and minimizes risks.

So how do you address these challenges? An excellent first step is to apply “The 7 R’s” framework to understand which of the “R’s” – such as rehost, relocate, replatform, or refactor – are aligned with your strategic objectives. Suppose you’re after a data center exit. In that case, the rehost or relocate approach for your entire application estate might be most appropriate. However, if your key change driver is to be more agile through modernization, you are likely to favour a mix of replatform and refactor for your strategic applications, and rehost or relocate your legacy.

Where do you go from here? You must break down your “7 R’s” migration strategy into something more specific to identify the AWS services you want to target for each of your technologies on-premises. We suggest agreeing on a framework of “patterns” that support your migration and modernization objectives and creating a mapping from your current architecture to the target architecture on AWS. The benefits of such a pattern framework are:

1. The patterns define available options for migrating each application;
2. They help you to be more specific about the benefits and costs of your migration;
3. They help you plan the build-out of your cloud platform, operations, and skills across the organization;
4. They enable you to scale through reuse of architecture blueprints; and
5. They allow you to create “migration factories” to speed up migrations using standardization and automation.

We recommend using a pattern framework as a central communication tool across different stakeholders throughout the migration.

Question from AWS: Zurich Insurance has embarked on a large-scale migration. How would you describe the critical success factors for this migration?

Alex Lopes, Zurich Insurance: First, we decompose this migration into smaller chunks. We will be migrating applications and not a full-blown data center. Each application is a different reality, but fortunately we can group these applications according to similar characteristics and thus simplify the approach by identifying how to deal with each set of defined characteristics. Here is where architecture patterns help. These provide options for each application migration, so we decomposed our big problem into smaller and simpler problems. Second, with clear options identified, we can group these by increasing the capabilities needed from the cloud landing zone. This landing zone needs to evolve, embracing higher pattern complexity levels. Third, we are highly cautious with security, which further helps us define the necessary guardrails for the landing zone. So, in summary: architecture patterns, evolving landing zone, and guardrails.

Migration patterns

The term “pattern” in technology refers to a reusable solution to a commonly occurring problem. In cloud migrations, you should first understand your on-premises application estate to identify relevant patterns. You can do this using automated discovery tools like the AWS Application Discovery Service. It collects and presents data regarding the configuration, usage, and interdependencies of applications you plan to migrate to AWS.

Once you have detailed data about your application estate, you should slice and dice it to get answers to the most important questions that will influence your migration approach. For example, what portions of your applications use a particular technology or database engine? What portions have technical debt? What portions are business critical? Based on the collected data points and your strategic objectives, you should decide on the changes in your application estate that you want to drive as part of the migration. For instance, what technologies do you want to invest in, sustain, or exit?

Based on your current state analysis and your modernization objectives, define your migration patterns. Do this by creating a matrix for each infrastructure layer in your applications, as shown in the following figure. The shown example indicates customer preference for AWS fully-managed services, given that services such as AWS Elastic Kubernetes Service (Amazon EKS) and Amazon Relational Database Service (Amazon RDS) are preferred compared to Amazon Elastic Compute Cloud (Amazon EC2). The sample matrix on the left-hand side indicates migration options for the application layer:

• The customer wants to invest in Apache Tomcat, sustain Microsoft IIS and exit IBM WebSphere as application server technology.
• AWS Elastic Beanstalk and Amazon EKS are preferred services to target. Amazon EC2 is reservered for exceptions.
• Applications running on IBM WebSphere will be migrated to Apache Tomcat.

Similiarly, the matrix on the right-hand side describes potential database migration options.

Figure 1. Identification of Relevant Migration Patterns.

After identifying the relevant patterns, we recommend you to create a pattern library that provides a comprehensive definition of each pattern, as indicated in the figure below. Define current and target state for each pattern and specify pre-conditions that state when the pattern is applicable. Classify the pattern according to the “7-Rs” migration strategies, link it to a set of benefits, costs, and skills required to support the target state. Migration factories are discussed later in the post. Consider referencing our AWS Prescriptive Guidance from your pattern library.

Figure 2. Elements of a Migration Pattern

When you migrate an application, you will typically apply multiple migration patterns. In the figure below, you apply an “IIS to EKS” pattern to containerize an ASP.NET application running on a Microsoft IIS web server to Amazon EKS and a “SQL Server to Aurora” pattern to move from Microsoft SQL Server to Amazon Aurora PostgreSQL-Compatible Edition.

Figure 3. Applying Multiple Patterns during a Migration

Selection of patterns across your application estate will influence your migration business case. For example, moving databases off SQL Server to Amazon Aurora PostgreSQL-Compatible Edition will result in run cost savings and increased portability and scalability, but is usually associated with higher migration costs. You should model different scenarios of pattern selection across your entire application estate to understand the business case implications before publishing pattern selection guidelines to your application teams.

Using patterns as a planning mechanism

You must build a cloud platform and operational capabilities to support the migration. In a regulated environment, you will need to define controls for each AWS service before making it available on the platform. Apart from implementing controls, services should be made available on the platform as code (e.g., in AWS CloudFormation) for consumption by the application teams during migration. Finally, different operational capabilities must be in place depending on the service. Use your customized pattern library to plan the iterative roll-out of your cloud platform with each platform iteration supporting more patterns and more applications.

In parallel to defining the platform roadmap, you must also plan your migrations and mobilize the required resources. Experience with large-scale migration shows that you should start simple and then progress to more complex applications and requirements, while consistently delivering business value. Migration planning is always a balancing act between business priorities, available resources, migration best practices, and alignment with the platform roadmap.

Patterns offer a way to estimate migration efforts and create a migration plan by forming groups of applications that use the same technologies on-premises that can be migrated together. Patterns also help you establish transparency regarding how the migration plan interlinks with the platform roadmap, as illustrated in the following figure. Experience shows that the beginning of the migration journey is the most challenging part. After that, the improvements to the cloud platform and migrations get more straightforward and quicker. Continuous delivery of business value is key to keep the momentum throughout the timespan of the migration program.

Figure 4. Patterns used in Platform Roadmap and Migration Planning.

The roll-out of training and enablement aligned with the cloud operating model will be a critical success factor for your cloud adoption journey, which also requires planning. We recommend aligning this plan with the migration plan and platform roadmap. This alignment ensures that the skills acquired in training can be directly applied in your internal cloud environment and made available through the platform.

Question from AWS: How important are patterns for the cloud migration program at Zurich Insurance?

Alex Lopes, Zurich Insurance: For this migration, the architectural patterns enable the grouping of the applications within defined characteristics that can prescribe a migration method. This removes complexity and uncertainty from the process, making it repeatable. It, therefore, assists with planning and costing within a common language between multiple stakeholders. At Zurich Insurance, we’re utilizing patterns as an established mechanism in our transformation journeys to achieve standardization, efficiency, cost reduction, scalability, improved service levels, and easier deployment of new services.

Creating migration factories

To increase the velocity of your migrations, you must create standardized and automated approaches to migrating applications applied by specialized migration teams, which are often referred to as “migration factories”. The standardization and automation of each pattern support the definition of migration factories.

Some migration factories will be highly automated. For example, rehosting applications to Amazon EC2 can be conducted in a largely automated manner using the AWS Server Migration Service by converting your source servers from physical, virtual, or cloud infrastructure to run natively on AWS. Migration factories for replatform patterns will be partially automated. For example, the AWS Schema Conversion Tool (AWS SCT) automatically converts the source database schema and most of the database code objects to a format compatible with the target database.

Other examples of integrating automation into migration factories include AWS App2Container, Porting Assistant for .NET, and Web Application Migration Assistant. A central pattern repository with AWS Service Catalog and a continuous delivery process with AWS CodePipeline allows for consistent and compliant migrations. For those patterns where only partial or limited automation is available, you must establish standardization by creating runbooks and considering automation scripts for repetitive tasks.

Question from AWS: How vital are standardization and automation for your migration to AWS?

Alex Lopes, Zurich Insurance: Standardization of migrations per pattern goes beyond automation and runbooks. For our organization, migration with standard pre-approved patterns ensures compliance and, thus, faster overall governance, reducing effort and delays in the process. Automation is essential in reducing errors, configuration drift, and delays. All migrations can be tested in non-production environments, and then automation will be used to replicate the process for production. The migrations result in a consistent setup that further enables automation and standardization of operations for the target state.

Summary

Large-scale cloud migrations can turn into complex transformation programs that take much longer than originally anticipated. Strategy alignment and continuous business value delivery are key to keep the momentum throughout the migrations. Use a pattern-based approach as a central tool to help you structure, plan and deliver your migrations at speed. Every customer is unique, and it’s important to remember that you might need to customize the approach we described here to fit your strategy and organization.

We’re interested to hear how patterns or other similar frameworks help you to accelerate your cloud adoption journey. Please post your thoughts in the comments section or get in touch!

About the authors: