Microsoft will retire its entire Azure NVv4-series GPU virtual machine fleet on September 30, 2026. After that date, any remaining instances will be forcibly deallocated—they stop working, stop billing, and lose all SLA and support coverage. The eight affected sizes range from the single‑GPU Standard_NV4as_v4 to the quad‑GPU Standard_NV32ahs_v4, and the migration isn’t a simple resize. A known operation error when moving to the recommended NVads_V710_v5 series requires pre‑registration of a feature flag, and the right replacement depends on your workload’s GPU vendor, frame buffer needs, and licensing.
The retirement: what’s being pulled
On September 30, 2026, Microsoft will deallocate all Azure NVv4‑series virtual machines. The specific SKUs entering retirement are:
- 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 sizes are powered by AMD Radeon Instinct MI25 GPUs and have been a workhorse for Windows virtual desktops, CAD, visualisation, and light inference. However, as of November 2, 2025, you could no longer purchase 1‑year or 3‑year reserved instances for them. All Cloud Solution Provider sales ended on June 2, 2026. The retirement date marks the final cut‑off: any NVv4 VM still running will be set to a deallocated state, meaning it stops functioning and stops incurring charges, but it also loses any service-level agreement or technical support.
This retirement does not affect the NVv3 series (Microsoft has a separate retirement guide for those) or any of the newer replacement families.
Which replacement fits your workload?
Microsoft’s primary recommendation is the NVads_V710_v5 series. That family uses AMD Radeon Pro V710 GPUs with 24 GB of frame buffer each and scales from 1/6 of a GPU up to one full GPU. However, the choice isn't automatic: your workload’s GPU vendor dependencies, frame buffer consumption, and licensing model must drive the decision. Microsoft itself lists two other valid targets—NVadsA10_v5 and NGads_V620—depending on what your VM actually does.
Here’s a practical mapping to help you pick a starting point for testing:
| Workload profile | Best starting target | Why |
|---|---|---|
| Windows AVD desktops, CAD, graphics applications, visualisation | NVads_V710_v5 | AMD Radeon Pro V710 options range from 1/6 to one GPU (4–24 GB frame buffer); supports both Windows and Linux. |
| NVIDIA‑dependent virtual apps or workflows needing NVIDIA GRID licensing | NVadsA10_v5 | NVIDIA A10 allocation from 1/6 to two GPUs, includes a GRID license; supports up to 25 concurrent users in virtual‑app scenarios. |
| High‑quality graphics streaming and interactive gaming | NGads_V620 | AMD Radeon Pro V620 partitions from 1/4 to one GPU (8–32 GB frame buffer); explicitly positioned for gaming and graphics streaming. |
| Small AI inference (SLMs, recommender systems, semantic search) | NVads_V710_v5 or NVadsA10_v5 | Microsoft lists both families for small AI; let application‑documented requirements, licensing, measured performance, and cost decide the pilot. |
This table identifies a sensible family to test first—it is not a compatibility guarantee. Every application, image, driver package, partition size, and concurrency target still requires validation. For most conventional Windows virtual desktops, NVads_V710_v5 is the most pragmatic starting point. But if your software vendor only certifies NVIDIA GPUs or you rely on NVIDIA GRID virtual workstation licensing, you must test NVadsA10_v5 first. If the workload is a game‑streaming service or demands extremely low‑latency graphics, NGads_V620 is likely a better fit.
For small inference teams, don’t assume that the two GPU options are interchangeable. Measure the actual model execution time, memory footprint, and throughput on the partition you plan to use, not against a generic benchmark.
The hidden blocker: why a resize isn’t enough
One of the most critical items in the retirement notice is a known error that occurs when resizing an NVv4 VM directly to an NVads_V710_v5 size. To unblock it, you must register your subscription for the Azure Feature Exposure Control flag VMTempDiskResizePreview. This isn’t a troubleshooting step to discover mid‑migration—it’s a prerequisite that must be completed and confirmed before you attempt the resize.
Microsoft’s procedure for this registration is specific to the retirement, so follow the instructions in the official retirement notice. Do not guess the feature namespace or command. After submitting the registration, verify that its status shows as Registered. A submitted request is not the same as a completed registration. Complete this step for every subscription that contains NVv4 VMs, and record the confirmation in your change ticket.
Beyond the flag, treat a simple “VM size change” as an insufficient migration plan. The fact that an infrastructure operation succeeds doesn’t prove that your Windows image, GPU driver, application certification, remote‑session experience, or user density will work. You need a deliberate validation process.
Timeline and context: from MI25 to V710
Azure’s NVv4 series launched with AMD Radeon Instinct MI25 GPUs, hardware that first appeared in 2017. While they served well for desktop‑as‑a‑service and entry‑level GPU tasks, the industry has moved on. The replacement families—NVads_V710_v5, NVadsA10_v5, and NGads_V620—are built on newer AMD Radeon Pro V710, NVIDIA A10, and AMD Radeon Pro V620 GPUs respectively. They offer better memory bandwidth, more efficient multi‑threading (the V710 line uses AMD Simultaneous Multithreading to assign dedicated vCPU threads), NVMe ephemeral storage, and broader size ranges that let you right‑size more precisely.
Microsoft stopped selling reserved instances for NVv4 on November 2, 2025, and ended Cloud Solution Provider sales on June 2, 2026. These sequential shutdowns gave early signals that the hardware was on the way out. Now the final retirement date is set, and the clock is ticking.
It’s worth noting that this retirement is separate from the NVv3 series retirement, so if you run both, you’ll need a different plan for each. Also, do not confuse the small‑scale GPU needs of an NVv4 virtual desktop with the massive AI training clusters that use NVIDIA GB200‑based VMs; those sit in a completely different class of infrastructure and are not part of this migration.
Your migration checklist: a step‑by‑step guide
Moving an entire fleet of GPU VMs feels daunting, but a phased, evidence‑driven approach reduces risk. Here’s a concrete sequence to follow:
1. Inventory and classify every NVv4 VM
List each VM by SKU, operating system, image, and its GPU‑dependent software. Tag it with the primary workload type: virtual desktop, virtual app, CAD/visualisation, graphics streaming, gaming, or small AI inference.
2. Determine the pilot target family per workload
Using the workload table above, pick the replacement family and document the specific partition (e.g., 1/6 of a V710, 4 GB frame buffer). Record any vendor‑lock requirements (AMD‑compatible, NVIDIA‑required, NVIDIA GRID‑required) for each workload.
3. Secure quota and check regional availability
Before you resize a single VM, confirm that your target family has sufficient quota in the deployment region. File quota requests early—Azure’s approval process can take time. Also verify that the chosen family and size are available in that region; not every size is offered everywhere.
4. Register VMTempDiskResizePreview if targeting V710
For any subscription that will move VMs to NVads_V710_v5, complete the AFEC registration and confirm the status is Registered. This is a hard blocker, so do it before your pilot window.
5. Pilot one VM per workload profile
Don’t move an entire pool at once. For each unique combination of image, application, and GPU dependency, pick one representative VM and resize it. Use Azure’s supported resize process, not a custom script, and plan for a maintenance window with recorded rollback criteria.
6. Validate at three levels after resize
- Infrastructure: Check the new VM size, OS boot, networking, storage access, monitoring agents.
- GPU platform: Confirm the GPU is detected with the expected allocation and frame buffer, driver health, any required licensing, and absence of device errors.
- Workload: Launch the production application, open realistic project data, exercise GPU‑intensive views, test remote session behaviour, and run with the intended number of concurrent users or requests.
Only after all three levels pass should you promote that size to a broader pilot wave.
7. Record everything
Create a migration record for each workload. Document the original NVv4 SKU, the chosen target family and partition, the test concurrency and outcomes, and the acceptance decision (promote, retest, change target, roll back). A note that “the VM resized successfully” is not an acceptance criterion.
8. Roll out in waves
Start with the least critical workloads or a small subset of users. If a wave fails, use your pre‑recorded rollback conditions rather than improvising. Expand the rollout only after each wave meets its acceptance criteria.
What comes next
Microsoft will almost certainly publish more detailed migration guides and tooling as the deadline approaches. Keep an eye on the official retirement page for any updates to the AFEC registration process or new quota‑management shortcuts. Additionally, if your Azure footprint includes other aging GPU series like NVv3, you’ll want to track their retirement timelines separately.
For now, the immediate priority is awareness: inventory your NVv4 estate, open a line of communication with your application vendors about GPU certification, and start budgeting for the engineering time needed to test and migrate. September 30, 2026 might feel distant, but GPU workload migrations have a habit of revealing hidden dependencies—and the last thing you want is to discover a critical CAD tool that only works on MI25 GPUs during a forced deallocation weekend.