Azure will discontinue the Dv3, Dsv3, Ev3, and Esv3 series on November 15, 2029
On September 30, 2026, Microsoft announced that the Dv3, Dsv3, Ev3, and Esv3 series would be discontinued as of November 15, 2029. Bookings have been closed since July 1, 2026; capacity restrictions are in effect; and the rules for exchanging bookings were modified on February 1, 2027: target series, prerequisites, and resizing procedure.
On September 30, 2026, Microsoft announced in the Azure Updates, the retirement of the Dv3, Dsv3, Ev3, and Esv3 virtual machine series in the following regions Azure the cloud . All four series are entering the End of Life phase of the virtual machine size lifecycle and will be retired on November 15, 2029. The retirement affects all 32 sizes in these series and does not apply to Azure Government, nor to Azure operated by 21Vianet, nor to sovereign cloud regions.
Existing machines will continue to operate and remain supported until that date. For those still using these models, three other deadlines will arrive well before 2029: capacity restrictions, effective as of July 2026; the end of reservations, effective as of July 1, 2026; and a change in the reservation exchange policy, effective as of February 1, 2027.
| Due Date | Effect |
|---|---|
| July 1, 2026 | End of purchases and renewals of one-year and three-year reservations for Dv3, Dsv3, Ev3, and Esv3 |
| July 2026 | Start of capacity growth restrictions: no new deployments since a new subscription was created, no quota increases |
| February 1, 2027 | Change to the exchange rules: An eligible active reservation purchased before this date retains one final exchange |
| November 15, 2029 | Withdrawal: You cannot create, resize to, run, or purchase these sizes |
Dates retrieved on October 12, 2026, from Microsoft documentation.
What Will Happen to Machines on November 15, 2029
On the retirement date, Microsoft deallocates virtual machines that are still running on a retired series. They stop functioning, are no longer billed, and are no longer covered by either a SLA or support. Data in memory and on the temporary disk is lost; data on managed disks is retained. To resume service, you must resize the machine to a supported size and restart it.
The Azure Updates also states that machines that have not been migrated may be deallocated and, eventually, deleted as the underlying hardware and platform infrastructure are phased out. The lifecycle documentation describes the deallocation and retention of managed disks. In both cases, a machine that has not been resized by November 15, 2029, will be shut down.
Capacity restrictions have been in effect since July 2026
Regardless of the phase-out, the Dv3, Dsv3, Ev3, and Esv3 series have been subject to capacity growth restrictions since July 2026. A new subscription cannot deploy these series. An existing subscription may continue to deploy and redeploy within the limits of its already-approved quota, subject to available capacity; requests for additional quota will not be approved.
A quota is an approved limit, not a capacity guarantee: a deployment may fail due to an allocation error if the region or zone no longer has available hardware, even if quota is available. A reservation does not protect against this situation. Microsoft reminds customers that a Reserved VM Instance is a billing benefit, not a capacity reservation: it does not guarantee creation, redeployment, disaster recovery, or failover if capacity is unavailable. Microsoft recommends that customers who need guaranteed capacity consider on-demand capacity reservations.
A disaster recovery plan that calls for recreating machines from these four series in another region therefore relies on capacity that Microsoft does not guarantee. Microsoft requests that you review your disaster recovery and restoration plans and update your reservations, savings plans, and capacity strategy based on the target environment.
Reservations: Limited exchange options after February 1, 2027; transfer to the savings plan remains unchanged
As of July 1, 2026, one-year and three-year subscriptions can no longer be purchased or renewed for these four series. Current subscriptions will continue until the end of their term. The process for expiration notifications and the full list of the eighteen series affected by this discontinuation are detailed in the article on subscriptions Azure for legacy series.
For those who continue to use these series before they are retired, Microsoft recommends theAzure Savings Plan for Compute as its primary recommendation. An existing reservation can be exchanged for a Savings Plan: the new Savings Plan—whether one-year or three-year—must have a commitment period at least equal to the remaining commitment period of the returned reservation, and up to 100 reservations can be exchanged in a single transaction. Microsoft currently does not charge early termination fees for these exchanges and states that it may charge such fees in the future, though it does not specify a date. Microsoft also clarifies that the change effective February 1, 2027, does not alter the policy for exchanging a reservation for a savings plan.
A reservation can also be exchanged for a reservation in a newer series. The total commitment of the new reservation must be at least equal to the remaining commitment of the old one, and the new reservation starts a full term anew as of the exchange date. Reservation exchanges are available through February 1, 2027; after that date, each eligible active reservation purchased before the expiration date retains one final exchange. Microsoft asks that you review your reservation portfolio before February 1, 2027, and plan how to use that final exchange for each eligible reservation.
A reservation does not carry over to the machine when resizing to a different series. Without an exchange or a switch to a savings plan, the discount may no longer apply, which could result in additional costs.
Target series and what changes with them
Microsoft classifies series into four stages: Current, Extended, End of Life, and Retired. For general-purpose sizes, v6 and v7 are Current, v4 and v5 are Extended, and the v1 through v3 series—for which retirement has been announced—are End of Life. Both Current and Extended series are fully supported.
| Current Series | Targets v5 | Targets v6 and v7 |
|---|---|---|
| Dv3, Dsv3 | Dv5, Dsv5, Ddv5, Ddsv5, Dasv5, Dadsv5 | D Series, Generations v6 and v7 |
| Ev3, Esv3 | Ev5, Esv5, Edv5, Edsv5, Easv5, Eadsv5 | E Series, Generations v6 and v7 |
Microsoft describes Generation v5 as the easiest transition for an existing workload, and Generations v6 and v7 as the path to the latest features and performance.
What Changes When Upgrading to Generation 5
Many basic v5 series, including Dv5, Dsv5, Dasv5, Ev5, Esv5, and Easv5, do not have a local temporary disk, whereas each of the 32 sizes—Dv3, Dsv3, Ev3, and Esv3—does. Under Windows, resizing is only allowed from a size with a temporary disk to a size with a temporary disk, or from a size without to a size without. Since the v3 series, the direct target under Windows is therefore a variant in d, such as Ddsv5 or Eadsv5; to target Dsv5 or Esv5, you must use the workaround documented by Microsoft, which involves taking a disk snapshot and then creating a new machine. Under Linux, resizing between the two categories is supported.
Accelerated Networking is required on the Intel D v5 series—namely, Dv5, Dsv5, Ddv5, and Ddsv5—and is supported on the AMD series and the E v5 family. Microsoft requires that it be enabled on the source machine before resizing it to a series that requires it. The v5 series of the D and E families support both Generation 1 and Generation 2 machines: in principle, a generation change is not necessary for resizing.
What Changes When Upgrading to Generation v6 or v7
The v6 and v7 series start with Generation 2 (UEFI), feature NVMe drives, and use the MANA network adapter, which requires an up-to-date system and drivers. The image must be a Generation 2 image that is ready for NVMe and MANA. The local drive is only available on sizes of d, and it is also implemented using NVMe. Microsoft requests that this transition be treated as a planned upgrade, rather than an in-place resize performed without preparation from an older family.
There are two additional limitations. A machine whose disks are presented as SCSI cannot be resized directly to a remote NVMe size; Microsoft recommends a workaround. And Azure Disk Encryption is not available on the v6 and v7 series, nor on Windows , nor on Linux; this service is also scheduled for deprecation on September 15, 2028, and its replacement, encryption at host, cannot be enabled on a machine that has, or has had, Azure Disk Encryption. In this case, Microsoft recommends rebuilding the system with new disks and a new machine, not a conversion.
Resizing a machine: the procedure and what it interrupts
The Microsoft modernization guide describes three steps: shut down the machine by deallocating it, resize it to the target series, and then restart it. Before doing so, you must verify that the subscription has sufficient quota for the target series and request more if necessary.
With Azure CLI, the command az vm list-vm-resize-options --resource-group <groupe> --name <machine> --query "[].name" lists the available sizes on the hardware cluster hosting the machine. If the desired size is not listed, deallocation allows the machine to be moved to another host. The Microsoft script then continues az vm deallocate, az vm resize --size <taille> and az vm start, each with --resource-group and --name. For more information, visit PowerShell, Get-AzVMSize -ResourceGroupName <groupe> -VMName <machine> returns the same list, and resizing is controlled by the property HardwareProfile.VmSize of the object returned by Get-AzVM, applied with Update-AzVM.
Resizing restarts the machine, even when deallocation is not necessary. Microsoft refers to this as a disruptive operation, particularly for stateful workloads. Deallocation frees up the machine’s dynamic IP addresses; the system and data disks are not affected. In an availability set, if the target size is not available on the cluster, all machines in the group must be deallocated for resizing.
If a resizing operation fails, the machine model displays the requested size, while the machine continues to run at the previous size until the allocation is successful. The portal and allAPI readings show the last applied configuration, not the size currently in use.
Our Reading
We would not treat this phase-out as a 2029 deadline. The two key dates are closer: the change in reservation exchange rules on February 1, 2027, and the capacity restriction already in effect, which undermines any recovery plan based on recreating machines from these series elsewhere. The inventory is therefore organized into two lists: active reservations with their expiration dates, and v3 machines with their dependencies on the temporary disk, boot generation, and Azure Disk Encryption.
For a machine Windows, we would aim for the v5 generation by resizing it to a variant in d : All v3 sizes have a temporary disk, and Windows only allows migration to a size that has one. Since v5 also supports Generation 1 and SCSI, an image from a local conversion does not need to be rebuilt for this migration. We would reserve Generation v6 for machines rebuilt from an up-to-date image, and for any machine encrypted by Azure Disk Encryption, which must exit this service by September 15, 2028, and which Microsoft is migrating to “encryption at host” via a rebuild. In all cases, we would enable Accelerated Networking and test the resizing on a stateless machine before making any changes to the database servers.
What to Check
- A list of Dv3, Dsv3, Ev3, or Esv3 machines, by subscription and by region, along with their role in a disaster recovery plan.
- Active reservations on these series, their expiration dates, and the decision to exchange them before February 1, 2027, or to roll them over into a savings plan.
- The quota available for the target series in each region, before any resizing.
- The local temporary disk, available on all v3 sizes: at Windows, direct resizing applies only to one variant in
d. - Enabling Accelerated Networking on the source machine before switching to Dv5, Dsv5, Ddv5, or Ddsv5.
- The boot generation, the type of disk controller, and the presence ofAzure Disk Encryption, which determine whether to resize or rebuild the disk.
- Availability sets, in which all machines may need to be deallocated together.
Microsoft Sources
- Retirement: Dv3, Dsv3, Ev3, and Esv3- Azure -VMs — Azure Updates
- Retirement: Azure Reserved Virtual Machine Instances for select VM series — Azure Updates
- VM Lifecycle Overview — Microsoft Learn
- VM size series retirements, capacity growth restrictions, and modernization guidance — Microsoft Learn
- Guide to Modernizing Retired VM Sizes — Microsoft Learn
- Upgrade to the v5 VM series — Microsoft Learn
- Upgrade to the v6 and v7 VM series — Microsoft Learn
- Frequently Asked Questions About Upgrading to the v6 and v7 VM Series — Microsoft Learn
- Resize a virtual machine — Microsoft Learn
- Self-Service Trade-In for Savings Plans — Microsoft Learn
- Self-Service Exchanges and Refunds for Azure Reservations — Microsoft Learn
What an article Can't Know
An article describes what applies to everyone. What varies from one organization to another is the inventory: which applications, which accounts, and which pieces of equipment are actually involved in your organization. The inventory determines the scope of the effort, and it cannot be summarized on a single page.
You'll be speaking directly with the engineers who will be doing the work, not with a middleman. We'll respond within 24 business hours.
Check what is still true
Announced dates are sometimes postponed, products are renamed, and conditions change. The blog tracks these topics over time: when a rule changes, a new post announces it.
Search for a topic in the blogIn the same issue
Three articles on the same topic. The blog has 151 articles, all of which are freely available.

