Overview & Impact.
This change is primarily a commercial lifecycle transition rather than an immediate compute shutdown. Starting July 1, 2026, new purchases and renewals stop for one-year RIs on Av2, Amv2, Bv1, D, Ds, Dv2, Dsv2, F, Fs, Fsv2, G, Gs, Ls, and Lsv2, and for both one-year and three-year RIs on Dv3, Dsv3, Ev3, and Esv3. Existing reservations continue delivering discounts until the end of their terms, but once a reservation expires the workload can silently fall back to pay-as-you-go pricing if no replacement commitment is staged. That is the core FinOps risk.
Architecturally, treat this as three separate planes: the running VM SKU, the cost coverage construct, and the hardware-generation lifecycle. Microsoft’s documentation explicitly states that Dv3/Dsv3/Ev3/Esv3 are not yet retired as runtime VM families, but their RI renewal/purchase path ends after July 1, 2026. Reservation decisions therefore need to be redesigned even when no urgent compute migration exists. For dynamic footprints, Microsoft positions Azure savings plan as the primary recommendation; for fixed footprints, reservations still make sense where the target generation is known.
Architecture & Deep Dive.
Instance Size Flexibility remains valid only inside the same flexibility group. A reservation bought for a DSv2 member can fan out across other DSv2 members according to ratio, but that does not carry over into Dsv5 or Dsv6 simply because the names look similar. That distinction is operationally critical during modernization. Microsoft also announced that the flexibility-ratio CSV stops receiving updates on May 9, 2026 and will be removed on August 30, 2026, pushing customers toward API or PowerShell-driven metadata. Any internal optimizer that still depends on the CSV is now a governance liability.
Step-by-Step Implementation & Scripts.
A practical migration factory starts with runtime inventory, then commercial coverage mapping, then controlled resize. Use Resource Graph to discover impacted VM families, validate target families such as Dsv5/Dsv6 or Esv5/Esv6 based on workload profile, and execute resize within a maintenance window. Reservation exchange or trade-in decisions remain portal-led according to Microsoft’s reservation guidance, while the runtime move itself is a standard deallocate/resize/start sequence.
az graph query -q “
resources
| where type =~ ‘microsoft.compute/virtualmachines’
| extend vmSize = tostring(properties.hardwareProfile.vmSize)
| where vmSize matches regex @’^(Standard_)?(A.*v2|B.*v1|D.*_v2|DS.*_v2|F.*|FS.*|Fsv2.*|G.*|GS.*|L.*s.*|Lsv2.*|D.*v3|DS.*v3|E.*v3|ES.*v3)’
| project subscriptionId, resourceGroup, name, location, vmSize
” -o table
az vm deallocate -g rg-prod -n appvm01
az vm resize -g rg-prod -n appvm01 –size Standard_D4ds_v5
az vm start -g rg-prod -n appvm01
Troubleshooting Guide & Common Edge Cases.
The most common failure mode is not an outage but a billing regression: the VM keeps running, the reservation expires, and finance sees a sudden PAYG spike. A second edge case is resize failure because the target SKU is unavailable in-region, unsupported for the current zone, or mismatched against temp-disk or image assumptions. A third is mistaken reliance on old measurement data: if your automation still reads the deprecated flexibility CSV, the optimization engine can recommend invalid reservation moves.
Best Practices.
Maintain a legacy-RI exit register with expiration date, successor SKU, test evidence, and replacement coverage decision. Separate runtime modernization from pricing modernization, even when both happen in the same sprint. Prefer savings plan when future family drift is likely, and prefer new-generation reservations only after the VM family target is stable and tested.