Convert Azure VMs from Unmanaged to Managed Disks: A Production-Ready Runbook

TL;DR

• Converting a VM to managed disks is usually operationally straightforward: deallocate, convert, start, validate.
• The real work is coordination:
  • availability set batching
  • maintenance windows
  • IP address behavior
  • validation and rollback plan
• Expect a possible post-migration background-copy window where reads can be slower.
• Do not skip cleanup: original VHD blobs and storage accounts can keep accruing cost after conversion.

Architecture Diagram

Table of Contents

• Scenario
• Core Concepts
• Prerequisites
• Version Compatibility Matrix
• Step-by-step
• Validation
• Troubleshooting Workflow
• Rollback Considerations
• Cost Model Snapshot
• Best Practices
• Conclusion

Scenario

You’ve identified one or more production VMs still using unmanaged disks. You need a runbook you can hand to an operations team that:

• minimizes human error
• scales across subscriptions and resource groups
• produces clear validation evidence for your change board

Core Concepts

• Unmanaged disks live as VHD page blobs inside a storage account.
• Managed disks are first-class Azure resources (disks) managed by the platform.
• The migration converts:
  • OS disk
  • attached data disks
• Constraints you must account for:
  • VM must be deallocated during conversion
  • availability set rules (no mixing disk types)
  • some scenarios can change IP behavior if you rely on dynamic assignment

Prerequisites

Operational prerequisites:

• Confirm you have:
  • VM owner approval
  • approved maintenance window
  • rollback plan
• Confirm backups:
  • Azure Backup recovery point exists and is recent
  • application-consistent backups where required

Technical prerequisites:

• VM is healthy:
  • provisioning state is good
  • extensions are healthy
• Networking plan:
  • if the VM must keep its IP, ensure the right static configuration is in place before you begin

Version Compatibility Matrix

Step-by-step

Step-by-step using Azure Portal

Use this when the count is low and you need a UI-backed change record.

• Open the VM
• Go to Disks
• Select Migrate to managed disks
• Review warnings:
  • availability set conversion requirements
  • downtime requirement
• Execute migration
• Start VM (if not auto-started) and validate

Step-by-step using Azure CLI

Use this for repeatability and batch execution.

For a single VM:

# Deallocate
az vm deallocate --resource-group <rg> --name <vm>

# Convert unmanaged -> managed
az vm convert --resource-group <rg> --name <vm>

# Start
az vm start --resource-group <rg> --name <vm>

For availability set VMs, plan to convert the availability set and migrate all VMs in the set in the same window:

# Convert availability set
az vm availability-set convert --resource-group <rg> --name <availabilitySetName

Step-by-step using Azure PowerShell

Use this for Windows-heavy ops teams and richer scripting.

Single VM conversion:

$rgName = "<rg>"
$vmName = "<vm>"

# Deallocate
Stop-AzVM -ResourceGroupName $rgName -Name $vmName -Force

# Convert (converts OS + data disks)
ConvertTo-AzVMManagedDisk -ResourceGroupName $rgName -VMName $vmName

Availability set conversion reminder:

• Convert the availability set to aligned SKU if required, then migrate all VMs in that set.

$rgName = "<rg>"
$avSetName = "<availabilitySet>"

$avSet = Get-AzAvailabilitySet -ResourceGroupName $rgName -Name $avSetName
Update-AzAvailabilitySet -AvailabilitySet $avSet -Sku Aligned

Validation

You want validation that proves:

• disks are now managed
• the VM boots and app is healthy
• monitoring and backups are still working

Resource Graph validation query

Resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend osDisk = properties.storageProfile.osDisk
| extend usesManagedOsDisk = isnotnull(osDisk.managedDisk)
| project subscriptionId, resourceGroup, name, location, usesManagedOsDisk

PowerShell validation

$vm = Get-AzVM -ResourceGroupName "<rg>" -Name "<vm>"
$vm.StorageProfile.OsDisk.ManagedDisk -ne $null

Validation checklist:

• VM status: running
• application health: synthetic transaction or service check
• disk performance: baseline read latency compared to pre-change
• backup: next scheduled backup job succeeds
• logging: heartbeats and metrics flowing

Troubleshooting Workflow

Common failure modes you should expect:

• Extensions not in a succeeded state
  • Fix extensions first, then retry migration.
• Availability set constraints
  • Ensure the availability set itself is migrated correctly and all VMs are coordinated.
• Snapshot count exceeded
  • Reduce snapshot counts and retry.
• IP changes
  • If you relied on dynamic addressing, ensure the correct static IP approach was applied prior to conversion.

Operator workflow:

• stop
• identify blocking error
• remediate the blocking condition
• retry the conversion command
• validate again

Rollback Considerations

This migration is best treated as non-reversible in place.

Practical rollback patterns:

• Keep the original VHD blobs and storage account until you pass an agreed validation period.
• If rollback is required:
  • recover using Azure Backup into a managed-disk VM workflow
  • or build a new managed disk from the original VHD and create a replacement VM

Rollback decision gates:

• boot failure
• application health failure after restart
• unacceptable latency for the workload

Cost Model Snapshot

Hidden costs people forget:

• After conversion, the original VHD blobs and storage account are not deleted automatically.
• If you leave them, you keep paying storage costs and sometimes transaction costs.

FinOps checklist:

• tag conversion date
• set a cleanup date
• delete old artifacts only after validation and sign-off

Best Practices

• Convert one low-risk VM first to validate your runbook end to end.
• Batch by dependency domain:
  • per app tier
  • per availability set
  • per maintenance window group
• Update IaC immediately after conversion:
  • templates and modules should no longer reference storage account VHDs
• Document the new steady state:
  • managed disks, backup behavior, operational runbooks

Conclusion

The conversion commands are easy. The success criteria are not. If you treat this like a production change with pre-flight, validation, and cleanup, you can migrate quickly without last-minute firefighting.

Sources

Migrate your Azure unmanaged disks by March 31, 2026: https://learn.microsoft.com/en-us/azure/virtual-machines/unmanaged-disks-deprecation
Convert a Windows VM from unmanaged disks to managed disks: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/convert-unmanaged-to-managed-disks
Convert a Linux VM from unmanaged disks to managed disks: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/convert-unmanaged-to-managed-disks
Frequently asked questions about disks: https://learn.microsoft.com/en-us/azure/virtual-machines/faq-for-disks
Migrate Azure VMs to Managed Disks in Azure: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/migrate-to-managed-disks