minor edits

Author: SnehaSudhirG

articles/update-manager/migration-key-points.md

@@ -43,8 +43,10 @@ This article lists the significant details that you must note when you're migrat
 
 - When the migration runbook is executed multiple times, say you did Migrate All automation schedules and then again tried to migrate all the schedules, then migration runbook runs the same logic. Doing it again updates the MRP schedule if any new change is present in SUC. It doesn't make duplicate config assignments. Also, operations are carried only for automation schedules having enabled schedules. If an SUC was **Migrated** earlier, it will be skipped in the next turn as its underlying schedule will be **Disabled**. 
 - In the end, you can resolve more machines from Azure Resource Graph as in Azure Update Manager. You can't check if Hybrid Runbook Worker is reporting or not, unlike in Automation Update Management where it was an intersection of Dynamic Queries and Hybrid Runbook Worker.
-- Machines that are unsupported in Azure Update Manager aren't migrated. The Schedules, which have such machines will be partially migrated and only supported machines of the software update configuration will be moved to Azure Update Manager. To prevent patching by both Automation Update Management and Azure Update Manager, remove migrated machines from deployment schedules in Automation Update Management. 
-- Remove the user managed identity created for migration that is linked with the automation account. For more information, see [Remove user-assigned managed identity for Azure Automation account](https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/how-manage-user-assigned-managed-identities?pivots=identity-mi-methods-azp#delete-a-user-assigned-managed-identity).
+- Machines that are unsupported in Azure Update Manager aren't migrated. The Schedules, which have such machines will be partially migrated and only supported machines of the software update configuration will be moved to Azure Update Manager. To prevent patching by both Automation Update Management and Azure Update Manager, remove migrated machines from deployment schedules in Automation Update Management.
+- **Post Deboarding**: 
+    - Remove the user managed identity created for migration that is linked with the automation account. For more information, see[Remove user-assigned managed identity for Azure Automation account](../automation/remove-user-assigned-identity.md#remove-using-the-azure-portal).
+    - [Delete the user managed identity](https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/how-manage-user-assigned-managed-identities?pivots=identity-mi-methods-azp#delete-a-user-assigned-managed-identity).
 
 Post-migration, a Software Update Configuration can have any one of the following four migration statuses: 
 

articles/update-manager/migration-troubleshoot.md

@@ -79,3 +79,9 @@ This error can come up while executing the Migration/Deboarding Runbook in Azure
 
 Delete custom Az Modules and ensure that default Az Module is updated to 8.0.0 for PowerShell 5.1
 
+## Next steps
+
+- [Migration using Azure portal](migration-using-portal.md)
+- [Migration using runbook scripts](migration-using-runbook-scripts.md)
+- [Manual migration guidance](migration-manual.md)
+- [Key points during migration](migration-key-points.md)