Microsoft has set a hard deadline for the retirement of its NVv4-series Azure virtual machines: September 30, 2026. After that date, any remaining VMs in this family will be forcibly deallocated—shut down, without a service-level agreement or ongoing support. The company is urging customers to migrate to newer, more capable GPU instances now, rather than risking service disruption later.
What exactly is being retired
The retirement covers eight specific VM sizes, all powered by AMD Radeon Instinct MI25 GPUs. The full list:
- Standard_NV4as_v4
- Standard_NV4ahs_v4
- Standard_NV8as_v4
- Standard_NV8ahs_v4
- Standard_NV16as_v4
- Standard_NV16ahs_v4
- Standard_NV32as_v4
- Standard_NV32ahs_v4
These are not minor variants; they represent the entire NVv4 family as it has existed for years. If you have a GPU-accelerated workload on Azure that’s not using the newer NVv3 or NVads series, it’s almost certainly running on one of these sizes.
Microsoft’s primary recommended replacement is the NVads_V710_v5 series, which uses AMD Radeon Pro V710 GPUs and AMD EPYC 9V64 F processors. The company sells it as a better fit for graphics-intensive desktops, visualization, and even lightweight AI inference—with more GPU memory bandwidth and up to 28 cores. Alternatives exist for specific workloads. The table below matches the typical use case to the recommended next destination.
| Workload | Recommended target SKU |
|---|---|
| GPU-accelerated graphics apps, virtual desktops, visualizations | NVads_V710_v5, NVadsA10_v5, NGads_V620 |
| Small AI tasks (SLM inferencing, semantic search, recommendation systems) | NVads_V710_v5, NVadsA10_v5 |
| Cloud gaming workloads | NGads_V620 |
None of these recommendations are one-size-fits-all. Regional availability and cost will further shape the decision, but the NVads_V710_v5 serves as Microsoft’s default north star.
The impact on your workloads
After September 30, 2026, any NVv4 VM that has not been resized or intentionally decommissioned will be placed into a deallocated state. That means the virtual machine stops running, its compute bill drops to zero, but its configuration—disks, network interfaces, the VM object itself—remains. You can still see it in the portal. You just can’t use it.
For a business, this is an outage in waiting. If an NVv4 VM hosts a session desktop for remote workers, a GPU-accelerated application server, or even a golden-image builder that churns out new virtual desktop images, the deadline is absolute. There is no grace period after the date. The SLA vanishes; no support ticket will spin the machine back up.
Powered-off VMs are a particular blind spot. A machine that has been stopped as a cost-saving measure may still be a critical piece of infrastructure scheduled for future use. The retirement doesn’t distinguish between a running VM and a stopped one—both are still NVv4 VMs that will be deallocated and rendered unusable. Organizations that rely on image-builders that only run once a month, for example, may not discover the problem until a new image is needed weeks after the deadline.
The commercial gates have already started closing. Microsoft stopped selling one-year and three-year NVv4 Reserved Instances on November 2, 2025. All Capacity Priority Program sales for the series ended on June 2, 2026. You can no longer lock in pricing or ensure priority capacity for these machines. The runway is shrinking, not stretching.
How we got here
The NVv4 series launched as a cost-effective option for GPU-accelerated Windows desktops and light visualization. Its MI25 GPU was shared among multiple VMs, with dedicated vCPU threads and low upfront costs. But GPU hardware moves fast, and the MI25 has been outclassed by newer silicon from both AMD and NVIDIA.
Microsoft’s push toward the NVads_V710_v5 is about more than performance. The V710 GPU offers dedicated hardware blocks for video encode and decode, larger memory buses, and better support for modern AI inference tasks that are creeping into everyday workloads. Letting the old family linger would fragment Azure’s GPU lineup and complicate capacity planning, especially as demand for AI-capable VMs surges.
Previous Azure retirements, such as the move from A-series or D-series v1 VMs, followed a similar pattern: ample notice, a recommended replacement, and a final forced change if customers didn’t act. The NVv4 retirement follows the playbook, with the added twist that regional capacity for GPU VMs is tighter now than in earlier transitions.
Your migration action plan
The official Microsoft guidance is simple: choose a target size, request the necessary quota, and resize. Execution is more involved. Here’s a practical walkthrough that accounts for the common snags.
1. Inventory all NVv4 VMs, not just the ones you think you have
Start with a tenant-wide query. Azure Resource Graph is the fastest way to do this because it searches across all subscriptions your account can access. Run the following in Azure Resource Graph Explorer:
Resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend vmSize = tostring(properties.hardwareProfile.vmSize)
| where vmSize in~ (
'Standard_NV4as_v4', 'Standard_NV4ahs_v4',
'Standard_NV8as_v4', 'Standard_NV8ahs_v4',
'Standard_NV16as_v4', 'Standard_NV16ahs_v4',
'Standard_NV32as_v4', 'Standard_NV32ahs_v4'
)
| project subscriptionId, resourceGroup, name, location, vmSize, tags, id
| order by subscriptionId asc, resourceGroup asc, name asc
Export the results immediately. This list becomes your migration registry. Over the following weeks, add columns for the owner, the intended target SKU, the migration window, and eventual disposition—whether the VM will be resized, rebuilt, or retired permanently. Avoid treating this as a one-time snapshot. Rerun the query monthly (or after each migration wave) to catch newly created NVv4 VMs from automated pipelines or forgotten templates.
Cast a wide net. The Azure Virtual Desktop host pool that your IT team monitors daily is only the most visible part of the estate. Look in test subscriptions, development sandboxes, inherited resource groups that predate current governance, and any subscription where “just a quick GPU server” might have been spun up years ago. Powered-off VMs appear in the query exactly like running ones—don’t filter by status.
2. Lock in your target and confirm it’s available
For each VM, decide on a replacement series. The NVads_V710_v5 is the default, but verify that it’s offered in the same Azure region. Use the Azure Regions by Product page to check. If the new series isn’t available in that region, you may need to rebuild the workload in a supported location—which might mean migrating data and networking configurations as well, not just resizing.
Quota is the next hurdle. GPU-family quota is tied to a subscription, a region, and a VM family. You can’t assume that because your production subscription has NVads quota, your test subscription does too. Request quota early, ideally before you schedule any cutover. Include headroom for temporary coexistence during testing: if you plan to run old and new VMs side-by-side for validation, your quota request must cover both.
3. Test with a representative sample
Before touching production, resize at least one NVv4 VM that mirrors each distinct workload—one session host, one visualization workstation, one image builder, and so on. The resize operation itself can hit a known error when moving from NVv4 to NVads_V710_v5. Microsoft documents this and requires you to register your subscription for the “VMTempDiskResizePreview” Azure Feature Exposure Control (AFEC) before the resize. Registration is not instantaneous; confirm it’s active before the cutover window.
For Windows workloads, the validation doesn’t end when the VM starts. Remote into the machine, launch the application, test interactive graphics responsiveness, confirm that user profiles and attached storage are intact, and reboot once more. A successful resize in the control plane is a necessary condition—it’s not sufficient proof that your users will be happy.
4. Plan migration waves, not a big bang
Group VMs by risk and business criticality. Start with nonproduction systems whose owners are available to validate the workload. Move next to low-impact standalone machines, image-building infrastructure, and finally persistent user-facing servers or desktops. Each wave should have a defined rollback path—even if that just means noting which backup snapshot or image to restore.
Document every production change: the source VM name, target size, quota confirmation, AFEC registration status (if applicable), and the person who will validate the application. After each wave, rerun the inventory query. The outstanding list should shrink only through documented migrations or approved retirements, never because someone deleted a row from a spreadsheet.
5. Don’t wait until Q3 2026
The deadline is more than a year from now, but quota requests, cross-region migrations, and internal change management take time. Some organizations will need to rebuild entire automation pipelines or golden images from scratch. Starting in early 2026 leaves breathing room for the unknown. Starting in September 2026 leaves none.
Outlook
Microsoft’s retirement notice is unambiguous: on October 1, 2026, NVv4 VMs will no longer be supported. The company wants customers on the NVads series not just for performance, but to standardize its GPU fleet and free up capacity for growing AI workloads. The forced deallocation is not a suggestion; it’s a final safety net for workloads that owners have ignored.
The organizations that breeze through this retirement will be those that began with a complete inventory now, mapped every machine to an owner, and built migration waves around real application testing. Everyone else will scramble when a critical desktop or builder suddenly won’t start—and by then, asking for emergency quota will be an uphill climb.