Microsoft has announced the retirement of the Dv3, Dsv3, Ev3, and Esv3 Azure VM series across public cloud regions. That is 32 sizes spanning the general purpose and memory optimized families, and a very large share of Azure estates still run on them. The machines are not going anywhere tomorrow. The off-ramps around them, though, are already closing.
The retirement table on Microsoft Learn puts the planned date at November 15, 2029. From that day you cannot create, resize into, run, or purchase any size in these four series. Azure Government, Azure operated by 21Vianet, and sovereign cloud regions are excluded, so this only bites the public cloud.
The dates that actually matter
Three years of runway sounds generous, and next to some of Microsoft’s past retirement notices it is. The problem is that the two deadlines with real teeth have already passed.
Capacity growth restrictions on these series began in July 2026. New subscriptions cannot deploy them at all, and quota increase requests get rejected. Existing subscriptions can still deploy within already approved quota, subject to capacity. So a team that spins up a new subscription today and tries to build on Dsv3 will be told no.
The other quiet deadline was July 1, 2026. One-year and three-year Reserved VM Instances for these series are no longer sold or renewed. Existing reservations run to the end of their term, but after that your options are exchanging eligible reservations for a target series or moving to the Azure savings plan for compute. If your finance team was planning to re-up a three-year RI block on Ev3 next year, that plan is dead.
What happens on retirement day
Until November 15, 2029, existing VMs keep running and stay covered by Azure SLAs. On the date, anything still running is deallocated. The VMs stop working, stop incurring charges, and lose SLA and support. In-memory data and temporary disk contents are gone. Managed disk data survives, and Microsoft documents the recovery path as resizing the VM to a supported series and starting it again.
That recovery path is fine for a stateless web tier. It is less fine for anything where an unplanned multi-hour outage in 2029 would ruin someone’s week. Which is exactly the kind of workload nobody remembers is sitting on an Esv3 until the ticket lands.
The v5 move is not a free resize
Microsoft’s modernization guidance points Dv3 and Dsv3 workloads at the Dv5 family and Ev3 and Esv3 workloads at the Ev5 family, with v6 and v7 series as the target if you want current-generation performance and features instead of the smoothest transition.
Two gotchas make this more than a click-through resize. First, the base v5 sizes dropped the local temporary disk. If your workload writes scratch data to D:\ or /mnt/resource, a plain Dv5 or Ev5 resize will land you on a machine without that disk. You need the ‘d’ variants such as Ddsv5 or Edsv5, and you want to know this before the resize, not after. Second, the Intel-based Dv5 sizes require Accelerated Networking, so some source VMs need a NIC change on the way through.
There is an upside hiding in here. A rebuild from a current image, rather than a live resize, gets you a Generation 2 VM and Trusted Launch security baselines that the v3 series never offered. Teams doing the migration work anyway should treat the generation bump as part of the job.
Retirement versus capacity restrictions
Microsoft splits this story into two mechanisms, and conflating them causes bad planning. Capacity growth restrictions are about hardware allocation: Azure will not guarantee you more Dsv3 capacity than you already have quota for, and it will not sell that capacity to new customers. Retirement is the calendar date after which the sizes stop existing for everyone. Microsoft’s FAQ is explicit that the restrictions do not mean the series is retired yet. Practically, you can finish a long-lived project on Esv3 within existing quota, but you cannot expand a fleet that depends on it, and you cannot move it to a fresh subscription. Any growth plan that assumes scaling out on v3 hardware is already broken, restrictions or no retirement date.
What to do this quarter
A Resource Graph query for vmSize in the affected list takes ten minutes and tells you exactly how exposed you are. While you are in there, note which machines actually use their temp disk and which have Accelerated Networking enabled, because those two facts decide how painful each migration is.
Then talk to whoever owns the reservations. Every month a lapsed RI runs on-demand is money burned on hardware you have promised to leave anyway.
This announcement is also a pattern, not a one-off. The D, Ds, Dv2, Dsv2, Av2, B-series v1, G, and Gs families are all scheduled to retire in 2028. Microsoft is clearing out its older hardware generations on a schedule now, and the v3 series is simply the next domino. If your estate has a corner nobody has touched since 2019, the next few announcements will find it eventually. Better to go looking first.