AWS prescriptive-guidance documentation change
Summary
Updated breadcrumb navigation, fixed apostrophe usage in contractions, restructured rollback section headings, corrected AWS Well-Architected Framework link, and improved AWS DMS reference formatting.
Security assessment
Changes are editorial improvements and formatting adjustments without introducing security-specific content. The rollback strategy discussion focuses on migration reliability rather than security vulnerabilities. No security advisories, vulnerability fixes, or new security features are mentioned.
Diff
diff --git a/prescriptive-guidance/latest/best-practices-migration-cutover/cutover-stage.md b/prescriptive-guidance/latest/best-practices-migration-cutover/cutover-stage.md index 0fe9150c4..87f266fc4 100644 --- a//prescriptive-guidance/latest/best-practices-migration-cutover/cutover-stage.md +++ b//prescriptive-guidance/latest/best-practices-migration-cutover/cutover-stage.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Best practices for cutting over network traffic to AWS](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Best practices for cutting over network traffic to AWS during a migration](introduction.html) @@ -7 +7 @@ -Cutover approachRollbackRollback during cutover or without new dataRollback with the changed data +Cutover approachRollback @@ -15 +15 @@ Cutover generally involves the following phases: - * **Ingestion freeze** – Freeze the ingestion of on-premises applications and data into the database. This ensures that the on-premises version of the application doesn’t receive any new transactions or data during the cutover. + * **Ingestion freeze** – Freeze the ingestion of on-premises applications and data into the database. This ensures that the on-premises version of the application doesn't receive any new transactions or data during the cutover. @@ -34 +34 @@ There are two cutover approaches to consider: an all-at-once approach or a phase -If you take the all-at-once approach, then you cut over the entire solution with a flip of a switch. For example, you can do this by updating the DNS or changing a load balancer. Then, all users and live traffic are immediately using the new system. This approach can be useful in scenarios where you can’t bring new systems online due to a potential host-name conflict, license issues, or domain authentication constraints. Because time is critical, the key emphasis is on when or who will call for a failback. We recommend that your plans for an all-at-once approach include extensive performance testing and, where applicable, regression testing, so that you can validate both functional and non-functional features of the application. +If you take the all-at-once approach, then you cut over the entire solution with a flip of a switch. For example, you can do this by updating the DNS or changing a load balancer. Then, all users and live traffic are immediately using the new system. This approach can be useful in scenarios where you can't bring new systems online due to a potential host-name conflict, license issues, or domain authentication constraints. Because time is critical, the key emphasis is on when or who will call for a failback. We recommend that your plans for an all-at-once approach include extensive performance testing and, where applicable, regression testing, so that you can validate both functional and non-functional features of the application. @@ -38 +38 @@ If you take the all-at-once approach, then you cut over the entire solution with -The phased approach involves a gradual cutover over a defined period of time. This approach includes continuous monitoring and checks to validate if the current system can sustain the load and if each system component is functioning as expected. A phased approach can help reduce the risk of potential cutover issues because you can adjust system performance based on feedback. It’s also easier to roll back any changes if you identify critical issues. +The phased approach involves a gradual cutover over a defined period of time. This approach includes continuous monitoring and checks to validate if the current system can sustain the load and if each system component is functioning as expected. A phased approach can help reduce the risk of potential cutover issues because you can adjust system performance based on feedback. It's also easier to roll back any changes if you identify critical issues. @@ -53 +53 @@ To choose the right approach, identify the following: -If you have an application that can’t tolerate increased latency between the data source and the application servers, this is a clear indicator that an all-at-once approach is required. In this scenario, you can cut over all the application resources (servers and databases) together to avoid impacting performance. +If you have an application that can't tolerate increased latency between the data source and the application servers, this is a clear indicator that an all-at-once approach is required. In this scenario, you can cut over all the application resources (servers and databases) together to avoid impacting performance. @@ -66 +66 @@ In a phased cutover, you split a percentage of the servers and services that con -The ability to send a percentage of your users to newly migrated servers in AWS while maintaining your existing on-premises capacity has a key advantage over an all-at-once approach when it comes to rollback capability. Because you have a mix of migrated and existing servers that serve the application with a load spread between them, it is both fast and simple to revert back in the event of issues. In most cases, all that’s required is a change to a load balancer, DNS rule, or policy. The phased cutover approach also lets you gradually increase load on AWS, which enables application teams to evaluate the performance of the application and make required updates or changes before the full load is transferred. +The ability to send a percentage of your users to newly migrated servers in AWS while maintaining your existing on-premises capacity has a key advantage over an all-at-once approach when it comes to rollback capability. Because you have a mix of migrated and existing servers that serve the application with a load spread between them, it is both fast and simple to revert back in the event of issues. In most cases, all that's required is a change to a load balancer, DNS rule, or policy. The phased cutover approach also lets you gradually increase load on AWS, which enables application teams to evaluate the performance of the application and make required updates or changes before the full load is transferred. @@ -68 +68 @@ The ability to send a percentage of your users to newly migrated servers in AWS -Choosing whether it’s best to cut over an application or stack of dependent applications all at once, or whether to use an incremental approach where servers and services are cut over in stages is unlikely to be a one-size-fits-all decision. We commonly see customers adopt the following approaches: +Choosing whether it's best to cut over an application or stack of dependent applications all at once, or whether to use an incremental approach where servers and services are cut over in stages is unlikely to be a one-size-fits-all decision. We commonly see customers adopt the following approaches: @@ -77 +77 @@ Choosing whether it’s best to cut over an application or stack of dependent ap -We recommend taking the time to understand your source systems prior to the cutover change window. By investing more time in the early planning stages, you can support various processes, such as cutover preparation and post-migration validation. Customers may change the IP addresses of their servers when migrating to AWS. In this scenario, the key factor to avoid is having hardcoded IP addresses inside your application. We recommend that you look holistically at your source environment, which can have both upstream or downstream dependencies. For example, you’re more likely to cause an issue to other systems that connect to the service you migrated. It’s worth considering if there’s value in moving all connections to use fully qualified domain names (FQDN) or DNS records prior to starting your cutover. +We recommend taking the time to understand your source systems prior to the cutover change window. By investing more time in the early planning stages, you can support various processes, such as cutover preparation and post-migration validation. Customers may change the IP addresses of their servers when migrating to AWS. In this scenario, the key factor to avoid is having hardcoded IP addresses inside your application. We recommend that you look holistically at your source environment, which can have both upstream or downstream dependencies. For example, you're more likely to cause an issue to other systems that connect to the service you migrated. It's worth considering if there's value in moving all connections to use fully qualified domain names (FQDN) or DNS records prior to starting your cutover. @@ -81 +81 @@ We recommend taking the time to understand your source systems prior to the cuto -In general, the best time for a cutover event is when you have the fewest users, as you’ll experience the least business impact. However, this needs to be balanced with availability of support teams during the cutover window. You need support teams to help troubleshoot and resolve potential issues. It’s also important to consider the date and time of the cutover along with stakeholder readiness. If any of your stakeholders are not prepared and available at the scheduled date and time, then your cutover can face the risk of delay. +In general, the best time for a cutover event is when you have the fewest users, as you'll experience the least business impact. However, this needs to be balanced with availability of support teams during the cutover window. You need support teams to help troubleshoot and resolve potential issues. It's also important to consider the date and time of the cutover along with stakeholder readiness. If any of your stakeholders are not prepared and available at the scheduled date and time, then your cutover can face the risk of delay. @@ -85 +85 @@ In general, the best time for a cutover event is when you have the fewest users, -If your migration approach permits, it’s a best practice to perform functional and non-functional testing ahead of the cutover window. For example, you can leverage load testing tools to validate if the new environment is appropriately configured ahead of the cutover window. In general, testing during this phase is non-disruptive as the AWS environment isn’t serving live traffic. +If your migration approach permits, it's a best practice to perform functional and non-functional testing ahead of the cutover window. For example, you can leverage load testing tools to validate if the new environment is appropriately configured ahead of the cutover window. In general, testing during this phase is non-disruptive as the AWS environment isn't serving live traffic. @@ -87 +87 @@ If your migration approach permits, it’s a best practice to perform functional -### What can’t be tested before cutover +### What can't be tested before cutover @@ -93 +93 @@ It might not be possible to test all scenarios that will happen in production du -Before you cut over your application to AWS, we recommend that you perform an operational readiness review. This is where you evaluate the completeness of the testing, validate the ability of your team to monitor and obtain alerts, and confirm that your stakeholders understand how to support and maintain the workload. This will likely require working with both business and technical teams. For more information on operational readiness, see the _Operational Excellence Pillar_ of the AWS Well-Architected Tool Framework from [AWS Well-Architected](https://aws.amazon.com//architecture/well-architected/) in the AWS documentation. +Before you cut over your application to AWS, we recommend that you perform an operational readiness review. This is where you evaluate the completeness of the testing, validate the ability of your team to monitor and obtain alerts, and confirm that your stakeholders understand how to support and maintain the workload. This will likely require working with both business and technical teams. For more information on operational readiness, see the _Operational Excellence Pillar_ of the AWS Well-Architected Framework from [AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/?wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc&wa-guidance-whitepapers.sort-by=item.additionalFields.sortDate&wa-guidance-whitepapers.sort-order=desc) in the AWS documentation. @@ -108 +108 @@ A migration rollback may be necessary under certain conditions. To prepare for a -## Rollback during cutover or without new data +### Rollback during cutover or without new data @@ -112 +112 @@ If you and your stakeholders decide to perform a rollback without any data being -## Rollback with the changed data +### Rollback with the changed data @@ -116 +116 @@ If a rollback is initiated after a successful cutover and your application has r - * **Fail-forward approach** – Your on-premises database is likely to become stale post-cutover since the post-migration AWS database becomes the main database. You can use [AWS Database Migration Service (AWS DMS)](https://aws.amazon.com//dms/) to set up a fail-forward database, which will replicate the data to a new on-premises database. In the event of any issues, AWS DMS rolls back your applications to a designated fail-forward database rather than to a stale on-premises database. + * **Fail-forward approach** – Your on-premises database is likely to become stale post-cutover since the post-migration AWS database becomes the main database. You can use [AWS Database Migration Service](https://aws.amazon.com/dms/) (AWS DMS)to set up a fail-forward database, which will replicate the data to a new on-premises database. In the event of any issues, AWS DMS rolls back your applications to a designated fail-forward database rather than to a stale on-premises database.