Key points to note for automated migration

Applies to: ✔️ Windows VMs ✔️ Linux VMs ✔️ On-premises environment ✔️ Azure Arc-enabled servers

This article lists the significant details that you must note when you're migrating using the portal migration tool or migration scripts.

Important reminders

• Non-Azure Saved Search Queries aren't migrated.

• 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 Log Analytics isn't migrated.

• User Managed Identities don't support cross tenant scenarios.

• RebootOnly Setting isn't available in Azure Update Manager. Schedules with the RebootOnly setting aren't 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. See the following examples:

  Automation schedule recurrence	Maintenance configuration schedule recurrence calculation
  100 hours	100/24 = 4.16 (Round to Nearest Value) -> every four days
  1 hour	Every 6 hours as it is the minimum value
  100 days	100/7 = 14.28 (Round to Nearest Value) -> every 14 weeks
  100 weeks	100/4.34 = 23.04 (Round to Nearest Value) -> every 23 Months
  Every 100 Weeks and must be Executed on Fridays	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 isn't migrated.
  More than 35 Months	35 months recurrence

• SUC (Software Update Configuration) supports between 30 Minutes to six Hours for the Maintenance Window. MRP (Maintenance Resource Provider) supports between 1 hour 30 minutes to 4 hours.

  Maintenance window in Automation Update Management	Maintenance window in Azure Update Manager
  30 minutes	one hour 30 minutes
  6 hours	Four 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 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.

• Post Deboarding:

  • Ensure to execute the script that will do the following:
    • Delete the automation account variable AzureAutomationAccountEnvironment created for migration.
    • Remove the user-managed identity created for migration from the automation account.
    • Delete the assigned roles for the user-managed identity created for migration.
    • Delete the user-managed identity created for migration.
  • To run the above script, you must have Microsoft.Authorization/roleAssignments/write permissions on all the subscriptions that contain Automation Update Management resources such as machines, schedules, log analytics workspace, and automation account. For more information, see how to assign an Azure role.
  • The script should be executed in the same manner as the Prerequisite script.

Post-migration, a Software Update Configuration can have any one of the following four migration statuses:

• MigrationFailed
• PartiallyMigrated
• NotMigrated
• Migrated

The following table shows the scenarios associated with each Migration Status:

Next steps

• An overview of migration
• Migration using Azure portal
• Migration using runbook scripts
• Manual migration guidance