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

Single VM conversion:

• 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

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

• 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

Operational 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

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

PowerShell validation

$rgName = “<rg>”
$vmName = “<vm>”

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

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

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

Technical prerequisites:

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

Hidden costs people forget:

$rgName = “<rg>”
$avSetName = “<availabilitySet>”

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

Validation

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.

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

Resource Graph validation query

FinOps 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

Use this for repeatability and batch execution.

• 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.

Practical rollback patterns:

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

Rollback Considerations

Rollback decision gates:

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

Step-by-step using Azure PowerShell

For a single VM:

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

Cost Model Snapshot

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

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

• 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

Operator workflow:

Sources

Common failure modes you should expect: