fixed broken links

Author: stephen-sumner

articles/azure-resource-manager/management/relocate-cutover.md

@@ -27,7 +27,7 @@ Cutover is when you direct traffic away from the source region and to the worklo
 
 ## Next steps
 
-**Repeat the Move phase for each workload.** If you have more workloads to relocate, return to the [Evaluate step](evaluate.md) and repeat the four steps of the Move phase until you complete the relocation project. Otherwise, you need to formally close the relocation project.
+**Repeat the Move phase for each workload.** If you have more workloads to relocate, return to the [Evaluate step](./relocate-evaluate.md) and repeat the four steps of the Move phase until you complete the relocation project. Otherwise, you need to formally close the relocation project.
 
 **Close project.** After you're done relocating, you should officially close the relocation project. Closure should take place two weeks after the final cutover. You need time to assess the success of the relocation and create a report for stakeholders to review. Business and technical stakeholders should review the report and approve.
 

articles/azure-resource-manager/management/relocate-index.md

@@ -17,7 +17,7 @@ The relocate guidance shows you how to set up a relocation project and relocate
 
 ## What is relocation?
 
-Relocation is the process of moving a workload or workload component in Azure to a different Azure region. A workload is a collection of applications, environments, services, and data that support a defined process. A workload can have one or many applications. Relocating a single or multi-app workload to a different region is a type of migration and has similarities with the process defined in the [migration to Azure guidance](../migrate/index.md). But relocation also has its own solutions and considerations to implement, and the relocate guidance here outlines these distinctive features to help you navigate the relocation process.
+Relocation is the process of moving a workload or workload component in Azure to a different Azure region. A workload is a collection of applications, environments, services, and data that support a defined process. A workload can have one or many applications. Relocating a single or multi-app workload to a different region is a type of migration and has similarities with the process defined in the [migration to Azure guidance](/azure/cloud-adoption-framework/migrate/). But relocation also has its own solutions and considerations to implement, and the relocate guidance here outlines these distinctive features to help you navigate the relocation process.
 
 :::image type="content" source="./media/relocate/single-multi-workload.png" alt-text="Diagram showing a single-app workload and a multi-app workload. There's a workload with a single application in it. The other workload has n applications in it, representing an indefinite number of applications. The applications in each workload show a production and nonproduction environments. In each environment, there's three representational services, one for compute, one for the database, and the other for an indefinite number of other Azure services." lightbox="./media/relocate/single-multi-workload.png" border="false":::
 
@@ -53,7 +53,7 @@ These phases define the lifecycle of a relocation project. It's important to not
 
 You should read relocation best practices and use them as guidance for each workload relocation. The following articles detail how you should approach each step. The content highlights critical areas to focus on but also refers you to other documentation for deeper technical insight. It assumes a basic understanding of Azure regions and service availability. For more information, see:
 
-- [Azure regions selection guide](../ready/azure-setup-guide/regions.md)
+- [Azure regions selection guide](/azure/cloud-adoption-framework/ready/azure-setup-guide/regions)
 - [Special conditions to consider when moving a resource](/azure/azure-resource-manager/management/move-support-resources)
 - [Azure Products by Region](https://azure.microsoft.com/explore/global-infrastructure/products-by-region/)
 - [Azure regions and availability zones](/azure/reliability/availability-zones-overview)

articles/azure-resource-manager/management/relocate-initiate.md

@@ -27,11 +27,11 @@ The need to meet specific objectives drives relocation projects. You should capt
 
 ## Determine relocation scope
 
-You should use the objectives to scope your relocation plan. Identify all the workloads in scope of these objectives. The workload should be the smallest unit of relocation during scoping. Anything smaller, such as environment or service, makes planning difficult to manage. In execution, you relocate workloads by migrating or redeploying workload services and components. But for planning and scoping, focus on the workload as a whole. For more information, see [What is a workload?](../plan/workloads.md#what-is-a-workload).
+You should use the objectives to scope your relocation plan. Identify all the workloads in scope of these objectives. The workload should be the smallest unit of relocation during scoping. Anything smaller, such as environment or service, makes planning difficult to manage. In execution, you relocate workloads by migrating or redeploying workload services and components. But for planning and scoping, focus on the workload as a whole. For more information, see [What is a workload?](/azure/well-architected/what-is-well-architected-framework#workload).
 
 ## Prioritize workloads for relocation
 
-The order you relocate workloads should reflect the priority of your objectives. Any technical dependencies, such as platforms and landing zones, should go first. Outside of technical dependencies, the order is up to you. For more information, see [Platform vs application landing zones](../ready/landing-zone/index.md#platform-landing-zones-vs-application-landing-zones).
+The order you relocate workloads should reflect the priority of your objectives. Any technical dependencies, such as platforms and landing zones, should go first. Outside of technical dependencies, the order is up to you. For more information, see [Platform vs application landing zones](/azure/cloud-adoption-framework/ready/landing-zone/#platform-landing-zones-vs-application-landing-zones).
 
 ## Create a relocation plan
 

articles/azure-resource-manager/management/relocate-migrate.md

@@ -42,7 +42,7 @@ You can begin migrating the services in your workload. For execution, follow ava
 - [Azure Resource Mover tutorials](/azure/resource-mover/tutorial-move-region-virtual-machines)
 - [Azure Site Recovery tutorials](/azure/site-recovery/azure-to-azure-how-to-enable-replication)
 
-You can create infrastructure-as-code templates or scripts for resources you can't move. You can also execute deployments manually in the Azure portal. The specific steps you follow depend on the Azure services you use and their configuration. For more information, see [Infrastructure as code overview](../ready/considerations/infrastructure-as-code.md).
+You can create infrastructure-as-code templates or scripts for resources you can't move. You can also execute deployments manually in the Azure portal. The specific steps you follow depend on the Azure services you use and their configuration. For more information, see [Infrastructure as code overview](/devops/deliver/what-is-infrastructure-as-code).
 
 ## Migrate data
 

articles/azure-resource-manager/management/toc.yml

@@ -44,7 +44,7 @@
       - name: Relocation overview
         href: relocate-index.md
       - name: Initiate relocation
-        href: relocate-portal.md
+        href: relocate-initiate.md
       - name: Evaluate workload
         href: relocate-evaluate.md
       - name: Select relocation strategy