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

Component	What you need	How you verify
Azure CLI	Azure CLI with az vm convert available	az version and az vm convert --help
Azure PowerShell	Az.Compute with ConvertTo-AzVMManagedDisk	Get-Command ConvertTo-AzVMManagedDisk
Permissions	At least Contributor on VM RG	Attempt a no-op read and confirm rights before change window

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