AWS prescriptive-guidance documentation change
Summary
Updated documentation links, fixed formatting issues, corrected table structures, standardized terminology (e.g., 'pods'), improved RACI matrix instructions, and fixed broken links including a security documentation reference.
Security assessment
The changes are editorial and structural improvements without addressing specific vulnerabilities. The security-related link update (security-risk-and-compliance.html → security-risk-compliance.html) fixes a broken reference but doesn't indicate a security incident. No new security guidance was added.
Diff
diff --git a/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.md b/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.md index 802294cb3..2ce66ffc6 100644 --- a//prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.md +++ b//prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Foundation playbook for AWS large migrations](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Foundation playbook for AWS large migrations](introduction.html) @@ -11 +11 @@ Best practices for team organization and compositionCreating RACI matricesCloud -###### This section includes the following topics: +This section includes the following topics: @@ -34 +34 @@ Team composition in a large migration varies by organization and changes over th - * **Design workstreams based on project scope and stage** – Every migration project is different, and one size does not fit all. We recommend having four core workstreams for all large migration projects: migration workstream, portfolio workstream, project governance workstream, and foundation workstream. You might decide to create additional, supporting workstreams depending on your use case. For more information about workstreams, see [Workstreams in a large migration](./workstreams.html). For example, if you have not yet designed the security guardrails in the mobilize phase, you need to create a security and compliance workstream that can define the security and compliance requirements before you start migrating. For more information about building the security guardrails in the mobilize phase, see [Security, risk and compliance](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/security-risk-and-compliance.html) in _Mobilize your organization to accelerate large-scale migrations_. + * **Design workstreams based on project scope and stage –** Every migration project is different, and one size does not fit all. We recommend having four core workstreams for all large migration projects: migration workstream, portfolio workstream, project governance workstream, and foundation workstream. You might decide to create additional, supporting workstreams depending on your use case. For more information about workstreams, see [Workstreams in a large migration](./workstreams.html). For example, if you have not yet designed the security guardrails in the mobilize phase, you need to create a security and compliance workstream that can define the security and compliance requirements before you start migrating. For more information about building the security guardrails in the mobilize phase, see [Security, risk and compliance](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/security-risk-compliance.html) in _Mobilize your organization to accelerate large-scale migrations_. @@ -36 +36 @@ Team composition in a large migration varies by organization and changes over th - * **Get the application team involved before the migration** – A large migration is never just an IT infrastructure project – it changes the operating model for your business. Involving the application team early and embedding the application owners into your large migration workstreams is critical to the success of large migration project. For example, during portfolio assessment, schedule your meetings early with application owners so that they can participate in the deep dive and help design their application’s target state on AWS. + * **Get the application team involved before the migration** – A large migration is never just an IT infrastructure project – it changes the operating model for your business. Involving the application team early and embedding the application owners into your large migration workstreams is critical to the success of large migration project. For example, during portfolio assessment, schedule your meetings early with application owners so that they can participate in the deep dive and help design their application's target state on AWS. @@ -38 +38 @@ Team composition in a large migration varies by organization and changes over th - * **Determine the team size based on workstreams and business outcomes** – Your expected business outcomes and migration strategies drive the size of each team, which is composed of smaller units called pods. In each workstream, you define teams for each migration strategy and then separate those teams into pods. For example, if rehost is your primary migration strategy, then you should have a rehost migration team that is composed of pods that contain 3–5 people. When operating at peak velocity, a pod of 4–5 people on a migration team can typically rehost up to 50 servers per week. This is approximately 200 servers per month or 2,500 servers per year. If your target is to rehost 100 servers per week, you should create two pods of 4–5 people within the rehost migration team. If you are targeting less than 50 per week, you can reduce the size of the migration pod to 3 people. Replatform migrations usually cost more than rehost, and the same size pod can migrate up to 20 servers per week. The portfolio workstream is usually half the size of the migration workstream. You create additional teams and pods in each workstream to support each migration strategy. These recommendations assume that your migration resources are skilled and do not require significant training. The following table is an example of how you would divide the migration and portfolio workstreams into teams and pods for the rehost and replatform migration strategies. The following example assumes that you need to migrate 120 servers per week (100 rehost + 20 replatform) or 6,000 servers per year. This example is the maximum velocity. We recommend that you plan for additional resources in order to help prevent delays. + * **Determine the team size based on workstreams and business outcomes** – Your expected business outcomes and migration strategies drive the size of each team, which is composed of smaller units called _pods_. In each workstream, you define teams for each migration strategy and then separate those teams into pods. For example, if rehost is your primary migration strategy, then you should have a rehost migration team that is composed of pods that contain 3–5 people. When operating at peak velocity, a pod of 4–5 people on a migration team can typically rehost up to 50 servers per week. This is approximately 200 servers per month or 2,500 servers per year. If your target is to rehost 100 servers per week, you should create two pods of 4–5 people within the rehost migration team. If you are targeting less than 50 servers per week, you can reduce the size of the migration pod to 3 people. Replatform migrations usually cost more than rehost, and the same size pod can migrate up to 20 servers per week. The portfolio workstream is usually half the size of the migration workstream. You create additional teams and pods in each workstream to support each migration strategy. These recommendations assume that your migration resources are skilled and do not require significant training. The following table is an example of how you would divide the migration and portfolio workstreams into teams and pods for the rehost and replatform migration strategies. The following example assumes that you need to migrate 120 servers per week (100 rehost + 20 replatform) or 6,000 servers per year. This example is the maximum velocity. We recommend that you plan for additional resources in order to help prevent delays. @@ -42,2 +42,2 @@ Workstream | Team | Pod | Resources -Migration workstream | Rehost migration team | Rehost migration pod 1 | 4–5 people -Rehost migration pod 2 | 4–5 people +Migration workstream| Rehost migration team| Rehost migration pod 1| 4–5 people +Rehost migration pod 2| 4–5 people @@ -46 +46 @@ Portfolio workstream | Portfolio team | Portfolio pod 1 | 3–4 people -Portfolio pod 1 | 3–4 people +Portfolio pod 2| 3–4 people @@ -55 +55 @@ Portfolio pod 1 | 3–4 people -A large migration project typically involves a lot of people, so building a governance model is important to manage the project. One of the key components of a governance model is a _RACI matrix_ , which is used to define the roles and responsibilities for all parties involved in the large migration. The name RACI matrix is derived from the four responsibility types defined in the matrix: +A large migration project typically involves a lot of people, so building a governance model is important to manage the project. One of the key components of a governance model is a RACI matrix, which is used to define the roles and responsibilities for all parties involved in the large migration. The name _RACI matrix_ is derived from the four responsibility types defined in the matrix: @@ -70 +70 @@ Because of the complexity of a large migration, we do not recommend using a sing -In the [foundation playbook templates](samples/foundation-playbook-templates.zip), you can use the RACI template (Microsoft Excel format) as a starting point for building your own high-level and detailed RACI matrices. This template includes two examples of detailed RACI matrices, one for a rehost migration and another for a replatform migration. The tasks in these examples are included for sample purposes only, and you should customize these examples based on your use case. +You can use the attached _RACI template_ (Microsoft Excel format) as a starting point for building your own high-level and detailed RACI matrices. This template includes two examples of detailed RACI matrices, one for a rehost migration and another for a replatform migration. The tasks in these examples are included for sample purposes only, and you should customize these examples based on your use case. @@ -103 +103 @@ Do the following to build your high-level RACI matrix: - 1. In the [foundation playbook templates](samples/foundation-playbook-templates.zip), open the _RACI template_ (Microsoft Excel format). + 1. Open the attached _RACI template_ (Microsoft Excel format). @@ -113 +113 @@ Do the following to build your high-level RACI matrix: - * If a party is **accountable** for the task, enter an **A**. + * If a party is **accountable** for completing the task, enter an **A**. @@ -138 +138 @@ After creating the high-level RACI matrix, the next step is to create a detailed - * **What are the detailed tasks in your migration?** After you have prepared the runbooks and task lists for your large migration project, the processes and details in these runbooks form the detailed layer of your RACI matrix. For example, for a rehost migration, detailed tasks might include installing a replication agent, verifying replication, and launching test instances for boot-up testing. If you haven’t done so already, follow the instructions in the following playbooks to create these documents: + * **What are the detailed tasks in your migration?** After you have prepared the runbooks and task lists for your large migration project, the processes and details in these runbooks form the detailed layer of your RACI matrix. For example, for a rehost migration, detailed tasks might include installing a replication agent, verifying replication, and launching test instances for boot-up testing. If you haven't done so already, follow the instructions in the following playbooks to create these documents: @@ -155 +155 @@ Do the following to build a detailed RACI matrix: - 3. Name the copied spreadsheet for a high-level task that you identified in Build a high-level RACI matrix. + 3. Name the copied spreadsheet for a high-level task that you identified in _Build a high-level RACI matrix_. @@ -163 +163 @@ Do the following to build a detailed RACI matrix: - * If a team is **responsible** for completing the task, enter an _R_. + * If a team is **responsible** for completing the task, enter an **R**. @@ -165 +165 @@ Do the following to build a detailed RACI matrix: - * If a team is **accountable** for completing the task, enter an _A_. + * If a team is **accountable** for the task, enter an **A**. @@ -167 +167 @@ Do the following to build a detailed RACI matrix: - * If a team should be **consulted** about the task, enter a _C_. + * If a team should be **consulted** about the task, enter a **C**. @@ -169 +169 @@ Do the following to build a detailed RACI matrix: - * If a team should be **informed** about the task, enter an _I_. + * If a team should be **informed** about the task, enter an **I**. @@ -171 +171 @@ Do the following to build a detailed RACI matrix: - 7. For each detailed task, confirm that only one team is responsible and only one team is accountable. If multiple teams are responsible or accountable, this can indicate that the task is not clearly defined or doesn’t have clear ownership. + 7. For each detailed task, confirm that only one team is responsible and only one team is accountable. If multiple teams are responsible or accountable, this can indicate that the task is not clearly defined or doesn't have clear ownership. @@ -180 +180 @@ Do the following to build a detailed RACI matrix: -For examples of detailed RACI matrices, see the **Rehost RACI** and **Replatform RACI** spreadsheets in the _RACI template_ , available in the [foundation playbook attachments](samples/foundation-playbook-templates.zip). +For examples of detailed RACI matrices, see the **Rehost RACI** and **Replatform RACI** spreadsheets in the attached _RACI template_. @@ -252 +252 @@ Portfolio lead | - * Overseeing the continuous supply of migration metadata and wave plans + * Overseeing the continuous supply of migration metadata and wave plans to the migration workstream @@ -297 +297 @@ Roles -Training and skills required +Training and skills required for large migrations