Globally unique resources that provide access to data management services and serve as the parent namespace for the services.
I'd plan for downtime. Microsoft hasn't documented the automatic conversion as a no-reboot operation. The retirement page only says that after 8 September 2028 the remaining Standard HDD OS disks are converted to Standard SSD of equivalent size, and that workloads "may experience a service disruption" if they weren't migrated first. That wording is the reason to convert on your own schedule.
What is documented today:
- Changing a managed disk type needs the VM stopped (deallocated). Learn says to schedule it in a maintenance window because it requires a restart. The type change itself is instantaneous, so the downtime is mostly the stop and start.
- Only OS disks are in scope. Standard HDD data disks, snapshots and Standard HDD OS disks created by Azure Site Recovery are not affected.
What I would do:
- List the affected disks (command from the retirement page):
az disk list --query "[?sku.name=='Standard_LRS' && osType!=null]" --output table - Per VM: take a snapshot, deallocate, change the OS disk to
StandardSSD_LRS(portal: VM > Disks > disk > Size + performance > Account type, oraz disk update --sku StandardSSD_LRS), then start the VM. - Verify with
az disk show -g <rg> -n <disk> --query sku.name, which should returnStandardSSD_LRS. - For VMs behind a load balancer or in an availability set, do them one at a time so the service stays up.
Limits: you can change a disk's type only twice per day. Premium SSD needs a VM size that supports premium storage, while Standard SSD doesn't. I haven't tested scale set instances, and the convert page's steps are written for individual VMs, so test one instance first. If you need a formal statement on how the automatic conversion will run, raise it through Azure support.
Sources: