Planning - AWS Prescriptive Guidance

Planning

You will assign each application, server, and database that you want to migrate to a wave. Each wave will have a start date and an end (cutover) date. The time between start and end dates can be as short as 2 weeks or as long as 20 weeks, depending on the activities required while preparing to cut over. Creating a high-level roadmap enables you to focus on the technical details of migrating specific workloads and how to migrate the set of workloads at the same time. The wave plan must account for dependencies between applications and infrastructure. Building this migration plan will help you understand what the migration timeline will look like and help you set expectations within your organization. The intent of the roadmap is to answer the common questions, “Which workload is moving and when?” and “How long will this migration project take?” The roadmap also provides clarity and focus of what needs to be worked on by the core migration team as well as ancillary teams.

When data collection is complete or sufficient (that is, it’s complete for one workload but not all workloads), you move on to the planning phase. In this phase, you do the following:

  • Assign applications and infrastructure elements to migration groups

  • Identify your initial migration strategy

  • Determine target Amazon Elastic Compute Cloud (Amazon EC2) instance types and Amazon Elastic Block Store (Amazon EBS) volumes

At this point, you can go back to the estimation stage to validate or refine estimates, although this is not required.

Creating the migration groups is a critical step to ensuring that you will be able to meet your migration end date. When you create migration groups, consider each dependency in your environment so that your business doesn’t experience unanticipated results when you migrate to the cloud. Groups are considered atomic migration units, so they should be consistent with workloads that must migrate at the same time.

Keep migration groups as small as possible, while also maintaining the integrity of the system’s performance during and after migration. Small migration groups are easier to switch around than larger groups. Small groups allow you handle the inevitable conflicts as they arise. For example, if there’s a last-minute priority 1 outage and you must move a group at a different time, you can adjust with a small group. Large groups don’t allow for this flexibility.

As a general rule, migration groups should not exceed 20 applications, 150 servers, and 30 databases. Migrating more than this in a single cutover can prove very challenging logistically. It also significantly raises your chances of failure, and might require rollback or an extended outage window. We recommend that you justify and critically examine any exceptions to this rule.

Focus most of your time on splitting up the largest groups. Find out if there are easy wins to split into smaller groups. For example, understanding a single dependency allows you to split the group in two. Remember that smaller groups enable more agility in the migration phase. However, this is a complex exercise to conduct on an entire portfolio, and so the analysis should focus on where you will get valuable agility. You don’t need to closely analyze every group. But you should review every group, even if only for a few moments.

Create migration groups

Creating migration groups is both an art and a science. You must make both data-driven and intuitive decisions. The fundamental idea behind migration groups is that you are establishing clear boundaries around what does and doesn’t need to migrate at the same time. To do this, you must look critically at the dependencies of your workloads.

The following are several key data points you must evaluate as part of assessing migration groups:

  • Shared databases

  • Shared servers

  • Application communication

There are other dependency types that could become a factor for migration groups. But this guide focuses on shared databases, shared servers, and application communication because they are present in nearly every environment and have the most significant impact on how your groups will be created.

Provided they do not have dependencies on each other, try to keep different application environments in different groups. For example, put the CRM production environment in a different group from the CRM development and test environments. This allows you to migrate the non-production environments first, so you can test your migration processes and configuration on AWS.

Evaluating shared databases

When you evaluate shared databases, focus on the following:

  • First, decide whether you plan to migrate the database or the server with all of its databases. Generally, we recommend moving the database by itself because it helps to create smaller groups, especially if you have a very large shared database server with many unrelated databases.

  • Second, decide whether the application must move with the database. An app server must be near a database server for performance reasons. Generally, the answer is going to be “yes, it must move together,” but researching this question can gain you significant flexibility in migration.

For example, Applications A, B, and C all connect to db01. A and B are both tightly coupled to the database, and they conduct many write and read operations every second. Application C, however, runs a batch job every night at off-peak hours. You determine that Applications A and B must move with db01, but Application C can move separately. Therefore, Application A, Application B, and db01 are placed in Group 1 and Application C is placed in Group 2.

Evaluating shared servers

Evaluating shared servers is often much easier than evaluating shared databases. Most organizations keep application servers dedicated to an application environment with a few common exceptions. A web server is an example of a common shared server. When deciding how to handle shared servers, try to figure out if the server function is easy to duplicate. In the case of web servers, this is often true because it is trivial to create a new server, install the web server software, and update the configuration.

For example, Applications A, B, and C all use an Apache web server for their web traffic. Applications A and B also share another application server, whereas Application C has its own dedicated application servers. You determine that Applications A and B will migrate with the Apache web server in Group 1. Application C will use a net new web server and migrate in Group 2.

Evaluating application communications

Understanding which applications must move together is where the art of this process starts to come into play. If you attempt to group everything that has a dependency you will likely find that a huge portion of your portfolio, sometimes as high as 80 percent, is connected through a chain of dependencies (for example, Application A requires Application B, which in turn requires Application C, and so on). Because it’s usually not feasible to migrate the majority of your portfolio at once, you will likely be forced to separate applications that you would ideally migrate at the same time.

This can be a challenging conversation to have with application subject matter experts because the default response is often, “No, they need to migrate at the same time; I need that application!” The way you phrase your question has a significant impact on getting the data-driven response. The question of whether applications must migrate at the same time is best stated as, “Are these applications tightly coupled?” If the answer is yes, dive deeper and ask these follow-up questions: “What would happen if these applications were offline at separate times?” and “What if they were separated geographically and had (for example) 30 ms of latency in their communication?” This will help you to understand where the limitations to separating applications into different groups truly are.

For example, Application A requires Application B. Application B requires Application C. You determine that if Applications A and B are migrated separately, there will be a significant performance impact to Application A. You also determine that Application B will lose a small portion of functionality while Application C is migrating and offline. You decide to put Application A and Application B in Group 1 and Application C in Group 2.

Tools to help

This process can be challenging, especially if you have no prior experience and a spreadsheet is the only tool you have available. We recommend that you find an AWS Partner Network (APN) Partner who has experience with this exercise and can help lead you through it. AWS Partners have access to tools and resources to assist with this analysis.

If you can’t use a partner, we recommend that you visualize the dependencies in your environment. Graph databases are an inherently good tools that can help you analyze your applications, databases, and servers as nodes or vertices, and then also ingest the dependencies as edges.

Other tools to support this process can be found in the migration tools catalog.

Turn the groups into a plan

When you have completed the migration grouping exercise, start scheduling the groups into waves. Each migration group should be assigned an anticipated start and end date. Groups with the same end date are considered part of the same wave.

Consider workloads that ideally migrate at the same time when assigning dates to each group. Successful migrations require significant contributions from many different parts of the business, so publish the migration plan across your entire business. Teams will want to review and schedule their contributions (for example, determine when they should communicate cutover times to users) and prepare themselves for the transformation by training, creating operational plans, and so on.

You might need some additional discovery as you work through the migration plan. These activities include a deep dive into the application architecture where you capture additional data required to successfully design, build, and migrate the application to AWS.