minor edits

Author: SnehaSudhirG

articles/update-manager/guidance-migration-automation-update-management-azure-update-manager.md

@@ -41,7 +41,7 @@ Guidance to move various capabilities is provided in table below:
 
 ## Scripts to migrate from Automation Update Management to Azure Update Manager
 
-Using the migration runbooks, you can automatically migrate all workloads (machines and schedules) from Automation Update Management to Azure Update Manager. This section details on how to run the script, what the script does at the backend, expected behavior, and any limitations, if applicable. The script can migrate all the machines and schedules in one automation account at one go. If you have multiple automation accounts, you have to run the runbook for all the automation accounts.
+Using migration runbooks, you can automatically migrate all workloads (machines and schedules) from Automation Update Management to Azure Update Manager. This section details on how to run the script, what the script does at the backend, expected behavior, and any limitations, if applicable. The script can migrate all the machines and schedules in one automation account at one go. If you have multiple automation accounts, you have to run the runbook for all the automation accounts.
 
 At a high level, you need to follow the below steps to migrate your machines and schedules from Automation Update Management to Azure Update Manager. 
 
@@ -58,19 +58,21 @@ At a high level, you need to follow the below steps to migrate your machines and
 ### Unsupported scenarios
 
 1. Update schedules having Pre/Post tasks won't be migrated for now.
-1. Non-Azure Saved Search Queries won't be migrated. They have to be migrated manually.
+1. Non-Azure Saved Search Queries won't be migrated; these have to be migrated manually.
 
 For the complete list of limitations and things to note, see the last section of this article.
 
 ### Step-by-step guide
 
 The information mentioned in each of the above steps is explained in detail below.
 
-#### Prerequisite 1: Onboarding of Non-Azure Machines to Arc
+#### Prerequisite 1: Onboard Non-Azure Machines to Arc
 
-**What to do**: The Migration automation runbook ignores resources that aren't onboarded to Arc. It's therefore a prerequisite to onboard all non-Azure machines on to Azure Arc before running the migration runbook. Follow the steps to [onboard machines on to Azure Arc](../azure-arc/servers/onboard-service-principal.md).
+**What to do**
 
-#### Prerequisite 2: Creation of User Identity and Role Assignments by running PowerShell script
+Migration automation runbook ignores resources that aren't onboarded to Arc. It's therefore a prerequisite to onboard all non-Azure machines on to Azure Arc before running the migration runbook. Follow the steps to [onboard machines on to Azure Arc](../azure-arc/servers/onboard-service-principal.md).
+
+#### Prerequisite 2: Create User Identity and Role Assignments by running PowerShell script
 
 **A. Prerequisites to run the script**
 
@@ -100,7 +102,7 @@ The information mentioned in each of the above steps is explained in detail belo
 **D. Backend operations by the script**
 
  1. Updating the Az.Modules for the Automation account, which will be required for running migration and deboarding scripts
- 1. Creation of User Identity in the same Subscription and resource group as the Automation Account. Name of User Identity will be like *AutomationAccount_aummig_umsi*. 
+ 1. Creation of User Identity in the same Subscription and resource group as the Automation Account. The name of User Identity will be like *AutomationAccount_aummig_umsi*. 
  1. Attaching the User Identity to the Automation Account.
  1. The script assigns the following permissions to the user managed identity: [Update Management Permissions Required](../automation/automation-role-based-access-control.md#update-management-permissions).
 
@@ -111,7 +113,7 @@ The information mentioned in each of the above steps is explained in detail belo
 
 #### Step 1: Migration of machines and schedules
 
-This step includes using an automation runbook to migrate all the machines and schedules from an automation account to Azure Update Manager.
+This step involves using an automation runbook to migrate all the machines and schedules from an automation account to Azure Update Manager.
 
 **Follow these steps:**
 
@@ -145,7 +147,7 @@ This step includes using an automation runbook to migrate all the machines and s
 
    1. You need to specify **ResourceGroupForMaintenanceConfigurations** where all the maintenance configurations in Azure Update Manager would be created. If you supply a new name, a resource group would be created where all the maintenance configurations would be created. However, if you supply a name with which a resource group already exists, all the maintenance configurations would be created in the existing resource group.
 
-1. Check Azure Runbook Logs for the Status of Execution and Migration Status of SUCs.
+1. Check Azure Runbook Logs for the status of execution and migration status of SUCs.
 
    :::image type="content" source="./media/guidance-migration-automation-update-management-azure-update-manager/log-status.png" alt-text="Screenshot that shows the runbook logs." lightbox="./media/guidance-migration-automation-update-management-azure-update-manager/fetch-client-id.png":::
 
@@ -154,7 +156,7 @@ This step includes using an automation runbook to migrate all the machines and s
 The migration of runbook does the following tasks:
 
 - Enables periodic assessment on all machines.
-- All schedules in the automation account are migrated to Azure Update Manager and a corresponding maintenance configuration is created for each of them, having same properties.
+- All schedules in the automation account are migrated to Azure Update Manager and a corresponding maintenance configuration is created for each of them, having the same properties.
 
 **About the script**
 
@@ -163,12 +165,12 @@ The following is the behavior of the migration script:
 - Check if a resource group with the name taken as input is already present in the subscription of the automation account or not. If not, then create a resource group with the name specified by the Cx. This resource group will be used for creating the MRP configs for V2. 
 - The script ignores the update schedules that have pre and post scripts associated with them. For pre and post scripts update schedules, migrate them manually.
 - RebootOnly Setting isn't available in Azure Update Manager. Schedules having RebootOnly Setting aren't migrated.
-- Filter out SUCs that are in errored/expired/provisioningFailed/disabled state and mark them as **Not Migrated**, and print the appropriate logs indicating such SUCs aren't migrated. 
+- Filter out SUCs that are in the errored/expired/provisioningFailed/disabled state and mark them as **Not Migrated**, and print the appropriate logs indicating that such SUCs aren't migrated. 
 - The config assignment name is a string that will be in the format **AUMMig_AAName_SUCName** 
 - Figure out if this Dynamic Scope is already assigned to the Maintenance config or not by checking against Azure Resource Graph. If not assigned, then only assign with assignment name in the format **AUMMig_ AAName_SUCName_SomeGUID**.
 - A summarized set of logs is printed to the Output stream to give an overall status of machines and SUCs. 
 - Detailed logs are printed to the Verbose Stream.  
-- Post-Migration, a Software Update Configuration can have any one of the following four Migration Statuses:
+- Post-migration, a Software Update Configuration can have any one of the following four migration statuses:
 
     - **MigrationFailed**
     - **PartiallyMigrated**
@@ -188,7 +190,7 @@ The below table shows the scenarios associated with each Migration Status.
 |  |  | Schedule associated with Software Update Configuration is disabled.|  |
 |  |  | Unhandled exception while migrating software update configuration.| Zero Machines where Patch-Settings failed to apply.<br><br> **And** <br><br> Zero Machines with failed Configuration Assignments. <br><br> **And** <br><br> Zero Dynamic Queries failed to resolve that is failed to execute the query against Azure Resource Graph. <br><br> **And** <br><br> Zero Dynamic Scope Configuration assignment failures. <br><br> **And** <br><br> Software Update Configuration has zero Saved Search Queries.|
 
-To figure out from the table above which scenario/scenarios correspond to why the software update configuration is having a specific status, look at the verbose/failed/warning logs to get the error code and error message.
+To figure out from the table above which scenario/scenarios correspond to why the software update configuration has a specific status, look at the verbose/failed/warning logs to get the error code and error message.
 
 You can also search with the name of the update schedule to get logs specific to it for debugging. 
 
@@ -210,7 +212,7 @@ You can also search with the name of the update schedule to get logs specific to
 
    :::image type="content" source="./media/guidance-migration-automation-update-management-azure-update-manager/verbose-log-records-deboard.png" alt-text="Screenshot that shows log verbose records setting while deboarding." lightbox="./media/guidance-migration-automation-update-management-azure-update-manager/verbose-log-records-deboard.png":::
 
-1. Start the runbook and pass parameters like Automation AccountResourceId, UserManagedServiceIdentityClientId, etc.
+1. Start the runbook and pass parameters such as Automation AccountResourceId, UserManagedServiceIdentityClientId, etc.
 
    :::image type="content" source="./media/guidance-migration-automation-update-management-azure-update-manager/deboard-runbook-parameters.png" alt-text="Screenshot that shows how to start runbook and pass parameters while deboarding." lightbox="./media/guidance-migration-automation-update-management-azure-update-manager/deboard-runbook-parameters.png":::
 
@@ -222,7 +224,7 @@ You can also search with the name of the update schedule to get logs specific to
 
    :::image type="content" source="./media/guidance-migration-automation-update-management-azure-update-manager/deboard-fetch-client-id.png" alt-text="Screenshot that shows how fetch client id while deboarding." lightbox="./media/guidance-migration-automation-update-management-azure-update-manager/deboard-fetch-client-id.png":::
 
-1. Check Azure runbook logs for status of deboarding of machines and schedules.
+1. Check Azure runbook logs for the status of deboarding of machines and schedules.
 
    :::image type="content" source="./media/guidance-migration-automation-update-management-azure-update-manager/deboard-debug-logs.png" alt-text="Screenshot that shows how runbook logs while deboarding." lightbox="./media/guidance-migration-automation-update-management-azure-update-manager/deboard-debug-logs.png":::
 
@@ -240,22 +242,22 @@ You can also search with the name of the update schedule to get logs specific to
 - The Migration and Deboarding Runbooks need to have the Az.Modules updated to work. 
 - The prerequisite script updates the Az.Modules to the latest version 8.0.0.
 - The StartTime of the MRP Schedule will be equal to the nextRunTime of the Software Update Configuration. 
-- Data from LA won't be migrated. 
+- Data from Log Analytics won't be migrated. 
 - User Managed Identities [don't support](../entra/identity/managed-identities-azure-resources/managed-identities-faq.md#can-i-use-a-managed-identity-to-access-a-resource-in-a-different-directorytenant) cross tenant scenarios.
 - RebootOnly Setting isn't available in Azure Update Manager. Schedules having RebootOnly Setting won't be migrated.
 - For Recurrence, Automation schedules support values between (1 to 100) for Hourly/Daily/Weekly/Monthly schedules, whereas Azure Update Manager’s maintenance configuration supports between (6 to 35) for Hourly and (1 to 35) for Daily/Weekly/Monthly.
-   - For example, if automation schedule has a recurrence of every 100 Hours, then the equivalent maintenance configuration schedule will have it for every 100/24 = 4.16 (Round to Nearest Value) -> Four days will be the recurrence for the maintenance configuration. 
-   - For example, if the automation schedule has a recurrence of every 1 hour, then the equivalent maintenance configuration schedule will have it for every 6 hours.
-   - Apply the same convention for Weekly & Daily. 
+   - For example, if the automation schedule has a recurrence of every 100 Hours, then the equivalent maintenance configuration schedule will have it for every 100/24 = 4.16 (Round to Nearest Value) -> Four days will be the recurrence for the maintenance configuration. 
+   - For example, if the automation schedule has a recurrence of every 1 hour, then the equivalent maintenance configuration schedule will have it every 6 hours.
+   - Apply the same convention for Weekly and Daily. 
      - If the automation schedule has daily recurrence of say 100 days, then 100/7 = 14.28 (Round to Nearest Value) -> 14 weeks will be the recurrence for the maintenance configuration schedule.
      - If the automation schedule has weekly recurrence of say 100 weeks, then 100/4.34 = 23.04 (Round to Nearest Value) -> 23 Months will be the recurrence for the maintenance configuration schedule. 
-     - If I have an automation schedule that should recur Every 100 Weeks and has to be Executed on Fridays. When translated to maintenance configuration, it will be Every 23 Months (100/4.34). But there's no way in Azure Update Manager to say that execute every 23 Months on all Fridays of that Month, so the schedule won't be migrated. 
+     - If the automation schedule that should recur Every 100 Weeks and has to be Executed on Fridays. When translated to maintenance configuration, it will be Every 23 Months (100/4.34). But there's no way in Azure Update Manager to say that execute every 23 Months on all Fridays of that Month, so the schedule won't be migrated. 
      - If an automation schedule has a recurrence of more than 35 Months, then in maintenance configuration it will always have 35 Months Recurrence. 
-   - SUC supports between 30 Minutes to six Hours for the Maintenance Window. MRP supports between one Hour 30 minutes to 4 hours.
-     - For Example, if SUC has a Maintenance Window of 30 Minutes, then the equivalent MRP schedule will have it for 1 hour 30 minutes.
+   - SUC supports between 30 Minutes to six Hours for the Maintenance Window. MRP supports between 1 hour 30 minutes to 4 hours.
+     - For example, if SUC has a Maintenance Window of 30 Minutes, then the equivalent MRP schedule will have it for 1 hour 30 minutes.
      - For example, if SUC has a Maintenance Window of 6 hours, then the equivalent MRP schedule will have it for 4 hours. 
-- 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 will run the same logic. Doing it again will update the MRP schedule if any new change is present in SUC. It won't make duplicate config assignments. Also, operations are carried only for automation schedules having enabled schedules. If a SUC was **Migrated** before, it will be skipped in the next turn as its underlying schedule will be **Disabled**. 
-- We can end up resolving more machines from Azure Resource Graph as in Azure Update Manager; we don'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.
+- 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 will run the same logic. Doing it again will update the MRP schedule if any new change is present in SUC. It won'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.
 
 ## Next steps