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  --name 

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

# Start
az vm start --resource-group  --name 

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  --name 



Step-by-step using Azure PowerShell



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



Single VM conversion:



$rgName = ""
$vmName = ""

# 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 = ""
$avSetName = ""

$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 "" -Name ""
$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 

Next Post
After You Migrate: Cleanup, Governance, and Preventing Unmanaged Disks from Coming Back
TL;DR Converting disks is not the finish line. Your real goal is a new steady state: no unmanaged disks no lingering storage account VHD costs guardrails that prevent reintroduction Cleanup…


Like this:
Like Loading...