Azure NVv3 GPU VMs Retire September 30, 2026: Migration and Windows Resize Risks

Which Azure VMs are affected?​

Microsoft identifies six retiring sizes:

• Standard_NV12s_v3
• Standard_NV12hs_v3
• Standard_NV24s_v3
• Standard_NV24ms_v3
• Standard_NV32ms_v3
• Standard_NV48s_v3

The notice specifically covers NVv3 machines powered by NVIDIA Tesla M60 GPUs. It does not cover NVadsA10_v5 or NVadsV710_v5; NVv4 has a separate retirement notice. One similar-looking name is not another series’ deadline.

NVv3 served graphics-heavy applications and virtual desktops, including CAD, visualization, simulation, rendering and streaming. Microsoft’s size documentation describes NVIDIA GRID technology paired with Intel Xeon E5-2690 v4 processors. Its three principal listed configurations range from 12 vCPUs and 112 GiB of memory to 48 vCPUs and 448 GiB. That matters when choosing a replacement: GPU capability is only part of the resource budget.

Choose the replacement around the workload​

Microsoft recommends NVadsA10_v5 as the primary migration destination. Its retirement guidance also identifies NC_RTXPRO6000BSE_v6 for graphics, virtual desktops, visualization and small AI workloads, and NCasT4_v3 for offline inference where latency is less important. Target selection should account for region, workload and cost—not just the closest-looking SKU name.

Microsoft’s NVadsA10_v5 specifications show why a direct name-based substitution is risky. The series uses NVIDIA A10 GPUs and AMD EPYC Milan processors, with fractional-GPU options starting at one-sixth of a GPU and a 4-GiB frame buffer. A full A10 configuration provides a 24-GiB frame buffer. Each instance includes a GRID license supporting a single-user virtual workstation or a virtual-application scenario with up to 25 concurrent users.

Our practical recommendation: validate a representative workload before committing the fleet. Test application responsiveness, rendering or inference behavior, memory pressure and user concurrency. A newer accelerator is not, by itself, evidence that the smallest replacement configuration can carry yesterday’s workload.

Migration has Windows-specific catches​

Microsoft’s general resizing documentation adds an important constraint beyond the retirement notice: Windows VMs cannot directly resize between configurations with a local temporary disk and configurations without one. NVv3’s listed sizes have local temporary storage, so check this characteristic on the proposed destination before assuming an in-place resize is supported.

Resizing is also disruptive. Microsoft says a running VM restarts when its size changes, and some changes require deallocation. Deallocation releases dynamically assigned IP addresses, although OS and data disks are unaffected. Schedule the change accordingly rather than treating the Resize button as a live upgrade.

For a compatible destination, Microsoft documents this Azure portal procedure:

1. Open Virtual machines and select the affected VM.
2. Under Availability + scale, select Size.
3. Choose an available compatible size and select Resize.

If the desired size is missing, stopping the VM may reveal additional options.

One final verification trap deserves attention: Microsoft warns that a failed resize can leave the displayed VM configuration showing the requested size while the machine still runs on its previous size. Do not declare migration complete from the size field alone; confirm successful allocation and application recovery.

The immediate priority​

For affected deployments outside UAE North, the general retirement deadline has arrived. Microsoft’s prescribed migration sequence is to choose a supported size, request target-family quota and resize. UAE North customers should use their extension to complete that work before January 31, 2027.

The useful outcome is not simply a different SKU in the portal. It is a supported VM that successfully runs the workload, with connectivity and application behavior validated after the change.