View a markdown version of this page

Wave planning - AWS Prescriptive Guidance
Creating a wave planManaging change

Wave planning

In essence, a wave plan is a migration schedule, and it is similar to other project-planning activities. We recommend that you use migration waves as a means to create manageable groups, reduce risk, and organize activities around those groups.

To create effective and high-confidence migration wave plans, you must obtain a complete view of the application portfolio, associated infrastructure (compute, storage, networks), dependency mapping, and migration strategy.

Besides business applications, which are a form of grouping a collection of software and infrastructure components, you can use other group levels. A wave is the highest group level. Within a wave, you can create dependency groups. This type of sub-group can contain more than one application. For example, two or more applications that need to be migrated at the same time due to technical dependencies, such as low latency, or other factors. Then that dependency group is managed as a whole. Multiple dependency groups can be assigned to a wave. Next, you can assign a migration date to the entire wave or to individual dependency groups within a wave. The migration date is the date and time when that group will be stopped on the current location and made active in AWS.

Migration waves have multiple activities. We recommend that you organize the wave in phases and set an expected duration for each phase. The phases below serve as an example:

  • Design: In this wave phase, the target design for each application in the wave is confirmed and approved.

  • Cutover planning: This wave phase includes the creation or iteration of cutover runbooks and planning of all steps required to switch over the application to AWS (including rollback scenarios).

  • Pre-migration: This phase includes landing zone deployment activities, such as account provisioning, configuration, premigration testing, migration tooling setup, and data replication.

  • Cutover: This phase is when the actual migration occurs. During this time, applications are stopped in the current location, data is synchronized for the last time, business testing is performed, and the migration is finalized. This phase includes operational handover.

  • Hypercare or Post-migration: This phase is a period of time where migration teams are available to support operations in case of issues. Also, optimizations can be applied as needed.

  • Wave closure: In this phase, you review metrics and lessons learnt and formally close the wave.

There is no predefined duration for a migration wave, and it will depend on the level of effort and complexity. We recommend to keep migration waves within 6 to 10 weeks. Cases where more time is required, for example, when completely re-writing an application component, are typically better handled outside of migration waves.

To measure success and track progress, waves should be aligned to outcomes and business drivers. This will also influence wave duration and the dependency groups that a wave contains. The completion of a wave should reflect a measurable achievement.

There are multiple ways to organize migration waves. The following table describes the most common wave organization options. These are usually combined.

Wave organization type

Description

Pros

Cons

By migration strategy or technology stack

Assign applications with a common migration strategy or pattern to a wave. For example, a wave containing only rehost applications.

Dedicated teams per pattern or stack can be assigned entire waves.

Homogeneous duration of activities.

Requires more analysis of dependencies, especially to applications that follow different patterns.

By business domain

Create waves per business domain. For example, an order management wave or a payments wave.

Shared data typically within a given domain.

Consistent team involvement.

Increased risk due to entire business domain being impacted.

By technical capability

Group applications that use one or more capabilities. For example, a compute-only wave or a compute + load balancing wave.

Migrations start faster as technical capabilities are enabled over time. Removes dependency for a fully operational landing zone.

Creates pockets of complexity in later waves.

By environment

A wave contains a specific environment for a set of applications. For example, a development wave or a production wave.

Non-production waves benefit from flexibility during execution.

Reduced risk to production migration.

Requires focus on dependency analysis to avoid missing dependencies not present in non-production environments.

By business priority

Creates groups purely based on a given prioritization criteria.

Addresses business outcomes.

Typically many teams involved; difficult to coordinate.

The section on establishing a baseline for the application portfolio described four categories of technical dependencies. These dependencies contribute to the creation of migration waves and the definition of dependency groups. Dependency groups will be determined by the criticality of the dependency. In addition, nontechnical dependencies must be considered. For example, application release schedules, maintenance windows, and key business dates (such as end of month or end of quarter processing) might influence the wave plan.

Determine whether the dependency is soft or hard. A soft dependency is a relationship between two or more assets, or from an asset to a constraint, that is not dependent on the location of the components. For example, two systems that operate in the same local network (or same infrastructure) can be split apart by moving one of those systems to the cloud while the other remains on premises. A hard dependency is a relationship between two or more assets, or from an asset to a constraint, that is dependent on location. For example, two systems that operate in the same local network, and that are heavily dependent on low latency for communication between the application server and the database server, have a hard dependency. Moving only one of these systems to the cloud would cause functionality or performance problems that cannot be resolved. Likewise, nontechnical reasons, such as resource availability (such as the team performing the migration) or operational constraints (such as maintenance windows where two systems can only be migrated in a given time window), might create a hard dependency for these assets.

To create a migration wave plan, determine your dependency groups by analyzing dependencies, ideally from a highly trusted source of data such as specialized discovery tooling. Combine this information with your application prioritization criteria and operational circumstances.

Determining technical dependencies is challenging. Several data points are required, and no source of data contains them all. For example, although you can obtain process-to-process communication information from discovery tooling, it is hard to classify them into soft and hard dependencies. Latency tolerance is also difficult to determine from network data alone.

The following techniques can help you handle the ambiguity of determining real dependencies:

  • Collect all data as described in the data requirements section and any other data points you have considered as needed.

  • Filter the dependency information (or communication data) and exclude shared services, such as Active Directory, backup, and monitoring traffic. Technical shared services tend to glue the entire scope.

  • Classify all the information. If available, use network frequency and data transfer volumes between components.

  • Meet with application owners, architects, and support teams. Discuss the type of connections. Are they synchronous or asynchronous? Are they aware of minimum latency requirements? What are the critical connections, and what happens if they are unavailable? Are you missing important connections? Consider that batch processes might occur sporadically and be missing in the data set.

  • If your discovery tool provides a data graph, look for single apps that bridge large clusters of applications. These single points of connection can help break the data into smaller groups.

AWS Transform can help you analyze dependencies and perform wave planning.

Creating a wave plan

A prerequisite to migrating a wave of applications is the application portfolio data and the detailed application assessment of the group of applications that will be migrated in the wave. The detailed assessment should include the list of applications in the wave, the associated infrastructure details, a target design, and a migration strategy for each application. 

Establishing wave ownership and governance is key to managing and tracking the wave work, program dependencies, change management, issues, and risks. Ensure that a governance framework is in place to manage the plan.

To outline the wave plan, start with a default wave construct. What happens within a wave? After the initial input is defined, the wave can commence. Typically, the activities will be: 

  1. Refine the cutover plan. This activity should outline the runbooks and steps that must be taken at the moment of migration, including the coordination with other internal and external teams.

  2. Refine the rollback plan. What must be done to roll back the applications if things go wrong?

  3. Prepare the target infrastructure. For example, you can create or extend the AWS landing zone (AWS account, security, networking, infrastructure services, other supporting infrastructure).

  4. Test target infrastructure.

  5. Operate migration tooling. For example, install replication agents and start data transfer.

  6. Conduct cutover plan and runbook dry runs. Group all participating team members, and review all steps in advance.

  7. Monitor data replication and infrastructure deployments.

  8. Confirm readiness for operation of infrastructure and applications in AWS.

  9. Confirm security readiness.

  10. Confirm compliance and regulatory requirements (for example, workload validation pre-migration and post-migration) if applicable.

  11. Migrate the applications to AWS and perform pre go-live testing.

  12. Provide post-migration support for a period of time, such as 3 days, when the operations teams and the migration teams are fully available to resolve issues, and apply optimizations.

  13. Conduct a post-migration review. Document lessons learned, and incorporate them into future waves.

  14. Perform wave closure by confirming operational handover and obtainment of metrics for reporting.

How long each of these activities takes will be dictated by the complexity of the scope, the wave capacity, the people involved, and your unique circumstances. Where possible, smaller waves are preferable because that will reduce the impact of any delays or migration blockers. Determine, with your teams, what the default duration of a wave will be.

Next, proceed to analyze dates to create an initial high-level structure of empty waves (with no application assigned yet). Consider the following questions:

  • What is the total migration program length? 

  • What are the deadlines?

  • Are there fixed data center exit dates? 

  • Are there collocation contract end dates? 

  • What are the application and infrastructure refresh cycles? 

  • What are the application maintenance and release cycles? 

  • Are there any dates when migrations should be avoided (for example, release and maintenance cycles, end of year, holidays, month-end processing)?

With these considerations, plot the waves into a plan. To accelerate the migration process, we recommend overlapping waves where possible. The key to overlapping waves is to define and consider what happens within a wave. Typically, deployment activities, target infrastructure validation, and data synchronization will occur during the first half of a wave. The second half will focus on the actual migration, testing, and operational handover. This means that different teams are involved in each half of the process, and that you can gain some efficiencies. For example, as soon as the team involved in target infrastructure preparation has completed their work, they can start working on the requirements of the next wave. In general, it is preferable that most waves have a similar length and structure to facilitate a factory-like approach to migrations. However, during the wave planning process, the size of a given wave can be extended to meet dependencies or operational requirements. 

Next, based on the dependency groups that have been identified, determine the maximum size of a wave in terms of the number of dependency groups it can contain. Wave size is typically dictated by risk appetite (for example, how much parallel change can be tolerated), and resource availability (for example, how much parallel change can be performed with the available resources, skills, and budget). However, during early planning, don't be limited by resource requirements and availability. Waves that contain more than one dependency group can be decomposed into smaller waves in future iterations.

After the dependency groups for a given wave have been confirmed, review resource requirements for migrating the wave. Consider adjusting the wave size (the number of dependency groups it contains) based on resource requirements. This might lead to smaller or larger waves. Iterate the wave plan as needed until all waves have been defined. Consider working with AWS Professional Services or AWS Migration Competency Partners, that can provide specialists to assist you throughout the process.

Managing change

The portfolio of applications and associated infrastructure will change during the lifecycle of migration programs. Long-running migration programs coexist with normal business evolution and change. Applications keep evolving as they wait to be migrated. Servers are added or removed, new infrastructure is deployed on premises. It is expected that the scope of a wave or dependency group will require changes. Changes are required especially when, closer to the migration date, a previously unknown dependency is identified, or a new server is included in the inventory. Sometimes this can happen during the migration itself.

Scope changes affect dependency groups and waves. To handle change and minimize impact, it's important to establish a scope-control mechanism. A scope change control mechanism requires the definition of a single source of truth for the scope. This could be a tool for managing the scope, or a .csv file, spreadsheet, or database, as defined by the migration program governance. You must identify changes, analyze impact, and communicate change to the relevant stakeholders so that they can take action. The wave plan will be iterated as a result.