Azure NVv4 Retirement: Prevent Windows GPU VM Deallocation With V710 AFEC Migration

What is retiring today​

Microsoft's retirement guide on Microsoft Learn lists eight sizes: Standard_NV4as_v4, Standard_NV4ahs_v4, Standard_NV8as_v4, Standard_NV8ahs_v4, Standard_NV16as_v4, Standard_NV16ahs_v4, Standard_NV32as_v4, and Standard_NV32ahs_v4. They all use the same hardware: the retirement covers eight specific VM sizes, all powered by AMD Radeon Instinct MI25 GPUs.

For anyone who hasn't looked at these machines in a while, Microsoft's NVv4 size documentation fills in the details:

• CPU: AMD EPYC 7V12 (Rome) processors, 4 to 32 vCPUs, 14 to 112 GiB of memory.
• GPU: Partial-GPU allocations. They start at one-eighth of an MI25 with 2 GB of accelerator memory (NV4as_v4) and go up to a full GPU with 16 GB (NV32as_v4).
• Guest OS: Windows only.
• Local temp disk: 88 GiB to 704 GiB, depending on size.
• Features: Generation 1 and Generation 2 VMs, Accelerated Networking and Ephemeral OS Disk are supported. Live Migration and Nested Virtualization are not.

Because NVv4 only supports Windows guests, this retirement mainly affects Windows shops. Typical workloads include Azure Virtual Desktop session hosts, remote workstations and GPU-accelerated Windows applications.

What's not affected: Microsoft says the notice doesn't cover NVadsA10_v5 or NVads_V710_v5 VMs. NVv3 is retiring on the same date, but it has its own guide. Microsoft's lifecycle page says NVv3-series and NVv4-series have announced retirements planned for September 30, 2026. The shared date makes it easy to mix up the two notices, especially since NVv3 uses NVIDIA hardware and NVv4 uses AMD.

Section summary: Eight AMD MI25-based NVv4 sizes retire today. NVv3 retires on the same date under a separate notice.

What happens after the deadline​

Microsoft says that after September 30th, 2026, any remaining NVv4-series virtual machines (VMs) subscriptions will be set to a deallocated state. They'll stop working and no longer incur billing charges. NVv4 will no longer be under SLA or have support included.

The end of billing is not good news. A deallocated VM costs nothing because it does nothing. There's no SLA and no support, so "leave it and figure it out later" means an outage that nobody has a plan for.

Microsoft's notice doesn't say that deallocation deletes managed disks, and we won't claim it does. Still, don't treat the disks as a recovery plan. The practical takeaway: capture or migrate anything you need while you can still reach it.

The Azure Batch angle​

Azure Batch pools have their own retirement notice. ReleaseBytes, summarizing a separate Azure update, reports that Microsoft is retiring support for NVv3 and NVv4-series virtual machines within Azure Batch pools on September 30, 2026. According to that summary, after the retirement date, new Azure Batch pools using NVv3 or NVv4-series VMs cannot be created. Existing pools will be unable to scale out and will face forced resizing to zero nodes.

If you run GPU jobs on Batch, check your pool definitions as well as your standalone VMs. Rendering or processing jobs that only scale up now and then are easy to miss in an inventory.

Section summary: Leftover NVv4 VMs are deallocated with no SLA and no support. Batch pools on NVv4 lose the ability to scale and get shrunk to zero nodes.

Where to migrate​

Microsoft's main recommendation is NVads_V710_v5. The retirement guide says the series has greater GPU memory bandwidth per GPU, and that it uses AMD Simultaneous Multithreading technology to assign dedicated vCPU threads to each VM and support NVMe for ephemeral local storage capability. At the top end, Microsoft lists one AMD Radeon Pro V710 GPU with 24 GB of memory, up to 28 AMD EPYC 9V64 F (Genoa) cores and 160 GiB of system memory. Those are maximums; smaller sizes get less.

Microsoft's workload table also names two alternatives:

Microsoft changed this table over time. An earlier copy of the guide in Microsoft's public docs repository on GitHub listed NVads_V710_v5 as the only target for both small-AI and graphics workloads. The current version adds NVadsA10_v5 and NGads_V620. If a migration plan was written from the older wording, recheck it.

Region availability​

The V710 recommendation only helps if that size exists in your region. One customer post on Microsoft Q&A describes an Australia East deployment where V710 wasn't offered. The AI-generated answer on that thread says NVads_V710_v5 isn't available in all regions, and suggests NVadsA10_v5 in the same region or V710 in a nearby region. That answer is machine-generated, not official guidance. The underlying problem is real, though: data residency and GPU capacity can decide your target before performance even comes up.

This is not a like-for-like resize​

Moving to NVadsA10_v5 means switching GPU vendors from AMD to NVIDIA. That can change drivers, application certification and licensing. Even staying with AMD on V710 means new silicon and a new driver stack. Our own earlier coverage recommended V710 for most Windows, AVD, CAD and visualization workloads, NVadsA10_v5 only where NVIDIA software or licensing is a hard requirement, and reserve NGads_V620 for graphics-streaming and gaming-oriented workloads. That's still a sensible default, but test your actual applications before you trust it.

Section summary: V710 is the default target, A10 and V620 cover edge cases, and region availability may make the choice for you.

The known resize error and its workaround​

Microsoft's guide warns about a known resize operation error that occurs when migrating from the NVv4-series to the NVads_V710_v5-series. The workaround is to register your subscription ID under the Azure Feature Exposure Control (AFEC) 'VMTempDiskResizePreview'. The AFEC is also discoverable in the portal. Then, confirm the AFEC registration status before resizing the VMs.

The history matters here. The older GitHub copy of the guide said Microsoft is working on a fix that will be implemented in April 2026. Microsoft's current guide, updated today, still tells customers to use the AFEC workaround. It doesn't say whether the April fix shipped. Assume the workaround may still be needed.

The feature name suggests the error involves temp-disk handling. That would fit the move from NVv4's local temp disk to V710's NVMe-based ephemeral storage, but this is our inference; Microsoft hasn't explained the cause. Microsoft also presents the workaround as the fix for this particular error, not as a required step for every migration.

Step-by-step: getting off NVv4​

Here is Microsoft's documented process, with the steps above placed where they fit:

1. Inventory. Find every VM, scale set and Batch pool using an NV*as_v4 or NV*ahs_v4 size, in all subscriptions and regions.
2. Choose a target series and size from the workload table, then check regional availability and pricing.
3. Request quota for the target VM family in the target region. GPU quota is often the slowest part.
4. If you're moving to V710, register the VMTempDiskResizePreview AFEC flag and confirm the registration has finished before you resize.
5. Resize the VM.
6. Check the result: the new GPU is visible in the guest, drivers are loaded, and your applications and users work normally.

If you get stuck and have a support plan, Microsoft's guide says to open a support request with these settings:

• Issue type: Technical
• Subscription: your subscription
• Service: My services
• Service type: Virtual Machine running Windows/Linux
• Summary: describe the problem
• Problem type: Assistance with resizing my VM
• Problem subtype: whichever applies

How we got here​

Microsoft's lifecycle table shows the NVv4 retirement was Announced | 04/15/25 | 09/30/26, so customers had about 17 months of notice. Microsoft also cut off new commitments along the way: 1-year and 3-year RI purchases for the NVv4-series ended November 2, 2025, and Microsoft's retirement guide says all NVv4 Compute Pre-Purchase sales ended June 2, 2026.

Microsoft's NV family page adds that after their retirement on September 30, 2026, NVv3-series and NVv4-series will be listed as previous-generation sizes.

Analysis: fair notice, awkward finish​

Microsoft gave plenty of warning, a clear primary target and documented alternatives. That's a reasonable way to handle a retirement.

Two things make it harder than it looks, though:

• The recommended target isn't available everywhere. A retirement plan that depends on a size missing from your region isn't a full plan for you.
• The recommended migration path had a known bug. Microsoft documented a resize error for V710, promised a fix, and still lists a feature-flag workaround in today's guide.

That said, a lot of the pain is self-inflicted. GPU VMs tend to be run by small teams with narrow roles, like a design group's remote workstations or a line-of-business visualization app. Those systems often sit outside the usual fleet reviews. If today's deadline surprised you, fix the inventory process as well as the VMs.

Bottom line: NVv4's retirement date is today. Resize to NVads_V710_v5, NVadsA10_v5 or NGads_V620 depending on your workload and region. Register the AFEC flag if you're headed to V710, and check your Batch pools too.