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-deprecationConvert a Windows VM from unmanaged disks to managed disks: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/convert-unmanaged-to-managed-disksConvert a Linux VM from unmanaged disks to managed disks: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/convert-unmanaged-to-managed-disksFrequently asked questions about disks: https://learn.microsoft.com/en-us/azure/virtual-machines/faq-for-disksMigrate Azure VMs to Managed Disks in Azure: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/migrate-to-managed-disks
Azure Unmanaged Disks Retirement: How to Tell If You’re at Risk Before End of March 2026
TL;DR Architecture Diagram Table of Contents Scenario You have Azure IaaS VMs that were built years ago. Some of them were created…
Next PostAfter You Migrate: Cleanup, Governance, and Preventing Unmanaged Disks from Coming BackTL;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…
The post Convert Azure VMs from Unmanaged to Managed Disks: A Production-Ready Runbook appeared first on Digital Thought Disruption.