AWS prescriptive-guidance documentation change
Summary
Significantly restructured content about migration wave planning. Added details about wave phases (Design, Cutover planning, Pre-migration, Cutover, Hypercare, Wave closure), wave duration recommendations, wave organization types table, dependency analysis techniques, and reference to AWS Transform.
Security assessment
The changes focus on migration planning methodology, dependency management, and operational phases. No security vulnerabilities, security incidents, or security-specific features are mentioned or addressed. Content about landing zone deployment is part of standard migration preparation without security-specific enhancements.
Diff
diff --git a/prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.md b/prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.md index a009090bf..a08cb49ae 100644 --- a//prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.md +++ b//prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.md @@ -11 +11 @@ Creating a wave planManaging change -In wave planning, a dependency group is a collection of applications and infrastructure that have technical and nontechnical dependencies that can't be resolved. Because of these dependencies the applications and infrastructure in a dependency group must be migrated at the same time or on a specific date. For example, an application running on a virtual machine and a database running in a separate virtual machine, where there are low-latency requirements or high-traffic volumes and complex queries, are likely to be migrated together rather than operating one component in the cloud and the other on premises. Likewise, independent applications that interact over an API with similar low-latency requirements will also be migrated at the same time. +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. @@ -13 +13 @@ In wave planning, a dependency group is a collection of applications and infrast -Migration waves typically span 4–8 weeks, and they can contain one or more migration events. Dependency groups are combined into waves so that a wave can contain one or more dependency groups. The wave also contains other activities that are required for the migration. These include AWS infrastructure setup (such as landing zone, security, and operations), migration tooling, and migration activities such as data replication, cut-over planning, testing, and post-migration support. +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. @@ -15 +15 @@ Migration waves typically span 4–8 weeks, and they can contain one or more mig -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. The planning of a wave can also combine other factors, such as technical guiding principles. For example, waves can be defined by environment (for example, development, test, production) or by migration strategy (for example, rehost wave, replatform wave). +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. @@ -17 +17,46 @@ To measure success and track progress, waves should be aligned to outcomes and b -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. +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](./baseline-application-portfolio.html) 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](./understanding-complete-assessment-data-requirements.html) 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. @@ -19 +64 @@ To create effective and high-confidence migration wave plans, you must obtain a -The section on [establishing a baseline for the application portfolio](./baseline-application-portfolio.html) 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 of end of quarter processing will influence the wave plan. + * 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. @@ -21 +66 @@ The section on [establishing a baseline for the application portfolio](./baselin -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. Another example is a system that can be migrated during a maintenance window without impacting maintenance activities. + * 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. @@ -23 +67,0 @@ Determine whether the dependency is _soft_ or _hard_. A soft dependency is a rel -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 (for example, 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. @@ -25 +68,0 @@ A hard dependency is a relationship between two or more assets, or from an asset -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, and combine this information with your application prioritization criteria and operational circumstances. The applications at the top of the prioritization ranking should be targeted for your initial migration waves. Determine wave capacity (the number of applications a wave can contain) based on resource availability, risk tolerance, business and technical constraints, experience, and skills. Consider working with AWS Professional Services or AWS Migration Competency Partners, that can provide specialists to assist you throughout the process. @@ -27 +69,0 @@ To create a migration wave plan, determine your dependency groups by analyzing d -The prioritization criteria are an initial indication of the order in which you will move your applications to the cloud. However, dependency groups will be the actual determinant for the applications that will be moved at a given time. This is because applications that are ranked as high priority could have hard dependencies to applications that are in the middle or at the bottom of the ranking. @@ -29 +71 @@ The prioritization criteria are an initial indication of the order in which you -The migration strategy will also influence the composition of a wave. For example, a high-priority application that requires a refactor strategy that might require several weeks or months of analysis, design, testing, and preparations will likely be placed in a later wave. +[AWS Transform](https://docs.aws.amazon.com/transform/latest/userguide/what-is-service.html) can help you analyze dependencies and perform wave planning. @@ -95 +137 @@ Next, based on the dependency groups that have been identified, determine the ma -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. +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.