Azure is finally retiring unmanaged disks by March 31, 2026. As a DevOps lead who’s cleaned up this mess before, here’s my practical, no-nonsense guide to migrating your disks without causing a production outage.

That Nagging ‘Unmanaged Disk’ Warning? Yeah, It’s Time to Deal With It.

I remember a 2 AM page. One of our ‘stable’ legacy finance apps, running on a VM named prod-fin-rpt-01, went completely offline. The monitoring lit up like a Christmas tree, but the VM itself was ‘running’. The cause? The underlying storage account for its unmanaged VHD hit its IOPS limit because a junior dev, bless his heart, had spun up a dozen test VMs in the same storage account to load-test a new feature, completely unaware it was shared. That’s the night I swore off unmanaged disks for good. They are a ticking time bomb of shared responsibility, and you’re the one holding it.

So, Why Is Microsoft Forcing Our Hand?

Let’s be clear: this is a good thing. Back in the early days of Azure, Unmanaged Disks were the only option. We had to create a Storage Account, manage its performance limits (IOPS, throughput), and then manually place our VHD files in it like it was a network share. If you put too many high-traffic disks in one account, like in my war story, everything slowed to a crawl.

Managed Disks fix this by abstracting the entire storage account layer away from you. You just ask for a disk of a certain size and performance tier (e.g., Premium SSD, Standard SSD), and Azure handles the rest. They provide:

• Better Reliability & SLAs: Azure manages the storage fabric, providing higher availability than a single storage account ever could.
• Massive Scalability: No more worrying about the 20,000 IOPS limit on a standard storage account. You can scale to thousands of VMs without manual sharding.
• Enhanced Security: Tighter integration with Azure services like Azure Disk Encryption and Private Links.

Essentially, Microsoft is removing a legacy feature that creates fragility and forcing us all to adopt a more resilient, scalable, and secure model. It’s a chore, but it’s for our own good.

Your Three Paths to Migration

Okay, enough theory. You’ve got VMs to migrate. Based on my experience, you’ve got three main ways to tackle this. We’ll go from the quick-and-dirty to the architecturally pure.

Option 1: The ‘Get It Done’ Portal Migration

This is your go-to for a single, non-critical VM you just need to fix. It’s the point-and-click method, perfect for that one old server, let’s call it dev-util-box-01, that you need to get compliant.

1. Navigate to the Virtual Machine in the Azure Portal.
2. On the Overview blade, you’ll see a banner if it uses unmanaged disks. If not, go to the ‘Disks’ blade.
3. Important: You must stop (deallocate) the VM first. This releases the file lock on the VHD. A simple restart isn’t enough.
4. Once deallocated, the ‘Migrate to managed disks’ option on the Disks blade will become active.
5. Click it. Azure will analyze the disks and perform the conversion. It’s surprisingly fast.
6. Once the migration is complete, start the VM.

Warning: This method requires downtime. The VM will be offline during the deallocation, migration, and startup process. Don’t do this to prod-db-01 in the middle of the workday without a maintenance window.

Option 2: The DevOps Way – Scripting the Fleet

If you have more than a couple of VMs, clicking through the portal is a recipe for mistakes and a waste of your time. This is where we earn our salaries. We script it. Here’s a basic Azure CLI script to find and convert a specific VM. You can easily wrap this in a loop to handle dozens of machines.

# Set your variables
RESOURCE_GROUP="rg-prod-legacy-apps"
VM_NAME="prod-sql-vm-01"

echo "INFO: Stopping and deallocating VM: $VM_NAME..."
az vm deallocate --resource-group $RESOURCE_GROUP --name $VM_NAME

echo "INFO: Starting migration to managed disks for VM: $VM_NAME..."
az vm convert --resource-group $RESOURCE_GROUP --name $VM_NAME

echo "INFO: Migration complete. Starting VM: $VM_NAME..."
az vm start --resource-group $RESOURCE_GROUP --name $VM_NAME

echo "SUCCESS: VM $VM_NAME has been migrated and is running."

This approach is repeatable, auditable, and much faster for bulk operations. You can build a list of target VMs, loop through them, and let the script do the heavy lifting. This is the professional way to handle a fleet of legacy servers.

Option 3: The Architect’s Choice – The ‘Nuke and Pave’

Sometimes, a migration isn’t a fix; it’s putting lipstick on a pig. If the VM in question is running an old OS, has been configured manually over years, and has no documentation, is it really worth preserving?

This is your chance to pay down technical debt. Instead of migrating the disk, you:

1. Redefine: Define the server from scratch using Infrastructure as Code (IaC) like Terraform or Bicep. Specify a Managed Disk from the beginning.
2. Rebuild: Deploy a brand new, clean VM based on your IaC definition.
3. Redeploy: Migrate the application and data to the new, pristine server.

Pro Tip: This sounds like the most work, and it is. But for a critical system like an old build server or a legacy web app, the long-term benefit of having a fully automated, documented, and reproducible server far outweighs the short-term pain of a manual migration.

Which Path Should You Choose?

Here’s how I break it down for my team:

Don’t Wait for the Deadline

March 2026 feels a long way off, but it’ll be here before you know it. Don’t let this turn into a last-minute fire drill. Use this deprecation notice as a forcing function to audit your environment. Find those unmanaged disks, categorize them, and make a plan. That nagging notification isn’t just a chore; it’s a great excuse to make your cloud environment more robust and reliable. Now go fix it.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions