I have a large number of Windows VMs currently running on B2s, B2ms, F2s, and D2s sizes. These older sizes can no longer be used with reservations, so our costs are likely to increase. I need to move the VMs to newer, reservable sizes while keeping the existing systems and data intact.
A direct resize fails because of differences involving temporary disks and the underlying storage technology. The options I've considered are restoring each VM with Veeam or creating an Azure image and redeploying, but some of these machines are very large and there are many of them. Around 60% are web front ends, so redeployment may be manageable, but I'd prefer a faster approach with minimal downtime and manual work. We use Windows with Azure Hybrid Benefit. What migration method has worked well for this situation?
3 Answers
For Windows VMs, check whether the page file is currently on the temporary disk. Move it temporarily to the C: drive, reboot if necessary, and then try resizing again. The page-file placement can prevent a resize when the destination size uses different temporary-disk or storage characteristics.
The exact source and target SKUs matter. For example, moving from B2ms to B2as_v2 may require deleting and recreating the VM while retaining the OS and data disks, whereas some F-series to Dads_v5 moves can work with a deallocate-and-resize operation. A scripted delete/recreate workflow can reduce the outage to roughly 15 minutes per VM, assuming the disks, network interfaces, public IPs, and other settings are preserved and reattached correctly.
With Hybrid Benefit, D-series options may be financially reasonable, but compare the reservation pricing and performance before choosing. If you want a newer F-series generation, the migration can be more involved because Gen2 and the NVMe controller may be required. For the web front ends, image-based or scripted redeployment could be the safest way to process many machines consistently.
The affected sizes are B2s, B2ms, F2s, and D2s, all running Windows with Hybrid Benefit. Since many are web front ends, I may pilot a scripted disk-preserving redeployment on a few of them and use a direct resize wherever deallocation and the page-file change are enough.
Before rebuilding anything, make sure the VM is fully stopped and deallocated rather than just shut down inside Windows. Some resize failures only occur while the VM is running, and deallocating it can make a normal resize work. It’s worth testing this on one of the less critical machines first.
That’s a useful possibility. I’ll test moving the page file first and see whether it allows the resize without rebuilding the VM.