AWS prescriptive-guidance documentation change
Summary
Updated navigation links, simplified section titles, consolidated paragraphs, updated image paths, corrected product names (AWS Transform MGN to AWS Application Migration Service), and improved link references.
Security assessment
Changes are administrative and editorial, involving navigation updates, image path corrections, and product name standardization. No security vulnerabilities, security procedures, or security features are mentioned or modified. The migration process documentation remains focused on operational governance without security implications.
Diff
diff --git a/prescriptive-guidance/latest/large-migration-intro-governance/preparing-organization.md b/prescriptive-guidance/latest/large-migration-intro-governance/preparing-organization.md index ee6a6bee8..2a4f58cb8 100644 --- a//prescriptive-guidance/latest/large-migration-intro-governance/preparing-organization.md +++ b//prescriptive-guidance/latest/large-migration-intro-governance/preparing-organization.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Introduction to governance for AWS large migrations](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Introduction to governance for AWS large migrations](introduction.html) @@ -9 +9 @@ Tagging strategyCloud operating modelBackup and administrationHypercare periodSe -# Preparing the organization for a large migration to the AWS Cloud +# Preparing the organization for a large migration @@ -11,3 +11 @@ Tagging strategyCloud operating modelBackup and administrationHypercare periodSe -For a large migration, your organization needs to scale up operational processes that directly or indirectly affect your ability to deliver the project on time and within budget. - -###### The following are key areas that you need to consider when preparing your organization: +For a large migration, your organization needs to scale up operational processes that directly or indirectly affect your ability to deliver the project on time and within budget. The following are key areas that you need to consider when preparing your organization: @@ -54 +52 @@ After you have completed the cutover, the migrated applications and servers ente -Define a process for handing off the workloads to the Cloud Ops team when the hypercare period is complete. In addition, as described in [Communication planning for a large migration to the AWS Cloud](./communication-planning.html), make sure that you have set up a communication process to notify application owners and other stakeholders when applications are entering or existing the hypercare period. +Define a process for handing off the workloads to the Cloud Ops team when the hypercare period is complete. In addition, as described in [Communication planning for a large migration](./communication-planning.html), make sure that you have set up a communication process to notify application owners and other stakeholders when applications are entering or existing the hypercare period. @@ -58 +56 @@ The following image shows an example of a hypercare process and the teams involv - + @@ -70 +68 @@ For each wave, the portfolio workstream runs 1–2 weeks, and the migration work - + @@ -72 +70 @@ For each wave, the portfolio workstream runs 1–2 weeks, and the migration work -The portfolio team prioritizes applications and then assigns them to waves in logical move groups. When planning waves, the portfolio team considers migration complexity, application similarities, and application and infrastructure dependencies. This helps make sure that the applications and their dependencies are migrated in their entirety. For more information about wave planning, see the [Portfolio playbook for AWS large migrations](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-portfolio-playbook/). For project governance, you manage and track information about the waves and sprints, including the applications, servers, and application owners. You might use a dashboard on a Confluence site, a list in Microsoft Excel, or a combination of tools. +The portfolio team prioritizes applications and then assigns them to waves in logical move groups. When planning waves, the portfolio team considers migration complexity, application similarities, and application and infrastructure dependencies. This helps make sure that the applications and their dependencies are migrated in their entirety. For more information about wave planning, see the [Portfolio playbook for AWS large migrations](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-portfolio-playbook/welcome.html). For project governance, you manage and track information about the waves and sprints, including the applications, servers, and application owners. You might use a dashboard on a Confluence site, a list in Microsoft Excel, or a combination of tools. @@ -76 +74 @@ The portfolio team prioritizes applications and then assigns them to waves in lo -As described in the [Understanding roles and responsibilities](./understanding-roles-responsibilities.html) chapter, you clearly define the tasks and task owners for the migration project. However, what this process will not identify is the key support processes that need to be in place before workloads are migrated to AWS. Support requirements might differ by region. If you have different support teams across multiple AWS Regions, you will need to determine who owns the responsibilities for each Region. +As described in the [Understanding roles and responsibilities for a large migration](./understanding-roles-responsibilities.html) chapter, you clearly define the tasks and task owners for the migration project. However, what this process will not identify is the key support processes that need to be in place before workloads are migrated to AWS. Support requirements might differ by region. If you have different support teams across multiple AWS Regions, you will need to determine who owns the responsibilities for each Region. @@ -82 +80 @@ Additionally, other third parties might be responsible for backing up or support -Migration _cutover_ is a finite window in which the source applications or servers are **cut** from on-premises infrastructure **over** to the AWS Cloud and go live. This is sometimes called a _migration party_ because it involves so many participants and stakeholders. The migration lead starts the migration cutover call. The call ownership is then transferred to the project manager. After the Amazon Elastic Compute Cloud (Amazon EC2) instances are launched in AWS Transform MGN, the infrastructure and application teams lead the call during the cutover validation phase. If your team is performing repetitive cutover tasks, we recommend you use [Cloud Migration Factory](https://aws.amazon.com/solutions/implementations/aws-cloudendure-migration-factory-solution/?did=sl_card&trk=sl_card) to cut over all servers in the migration wave. +Migration _cutover_ is a finite window in which the source applications or servers are **cut** from on-premises infrastructure **over** to the AWS Cloud and go live. This is sometimes called a _migration party_ because it involves so many participants and stakeholders. The migration lead starts the migration cutover call. The call ownership is then transferred to the project manager. After the Amazon Elastic Compute Cloud (Amazon EC2) instances are launched in AWS Application Migration Service, the infrastructure and application teams lead the call during the cutover validation phase. If your team is performing repetitive cutover tasks, we recommend you use [Cloud Migration Factory](https://aws.amazon.com/solutions/implementations/aws-cloudendure-migration-factory-solution/?did=sl_card&trk=sl_card) to cut over all servers in the migration wave.