Azure DCsv3/DCdsv3 Retirement: SGX VM Migration Deadline and Replacement Options

Three years sounds like a long time. In infrastructure terms it isn't, especially for workloads built around Intel SGX enclaves. There is also an earlier date that matters: November 1, 2026, one month from now.

The dates that matter​

The announcement has two milestones, and the earlier one is easy to miss.

On support during the run-up, Microsoft says support continues for workloads on DCsv3/DCdsv3 virtual machines until the retirement date, and customers continue to receive SLA assurance, infrastructure updates, and maintenance. Once the date passes, any remaining DCsv3/DCdsv3 VM subscriptions stop working. That is a hard shutoff, not a quiet end of support.

The November 2026 restriction is short on detail. The guide places it under the question of whether new customer sign-ups are still allowed and answers with capacity restrictions and no new subscriptions. It does not say whether existing customers can still scale out. If your plans for the next year assume adding DCsv3/DCdsv3 capacity, check with Microsoft before you depend on it.

Microsoft also says it will stop building new features for these series and will not bring them to new Azure regions. The VM lifecycle page in Microsoft Learn lists DCsv3/DCdsv3-series with an "Announced" retirement status and a planned retirement date of 10/31/29.

Section summary: The hard deadline is October 31, 2029. Restrictions on new subscriptions arrive November 1, 2026, so planning should start now.

It reaches beyond standalone VMs​

This retirement covers every way the SKU is used, not just individual VMs. Microsoft's FAQ says that customers running workloads on DCsv3/DCdsv3-series through Azure Linux, Windows, and Dedicated Host virtual machines, Virtual Machine Scale Sets, or app-enclave aware containers on Azure Kubernetes Service are affected. It also states that all uses of the DCsv3/DCdsv3 SKU retire simultaneously in October 2029, including those on Azure Kubernetes Service and Azure Virtual Machine Scale Sets.

For admins, an inventory that only lists individual VM resources will miss things. AKS node pools running SGX-enabled containers and scale sets that use these sizes also have to move. Microsoft's guide provides no inventory script or query, so use whatever discovery process your organization already has across subscriptions, scale sets, Dedicated Hosts and AKS clusters.

Section summary: Count VMs, scale sets, Dedicated Hosts and AKS enclave workloads. They all retire on the same day.

Why this isn't a simple resize​

These are not general-purpose VMs that you can resize to a newer generation in an afternoon. Microsoft's size documentation describes the DCsv3-series as helping to protect the confidentiality and integrity of code and data while being processed in the public cloud, using Intel Software Guard Extensions and Intel Total Memory Encryption - Multi Key. The hardware is 3rd Generation Intel Xeon Scalable processors using Intel Turbo Boost Max Technology 3.0 to reach 3.5 GHz. The series tops out at 48 cores, with encrypted memory (EPC) of 256 GB and regular memory of 384 GB.

The DCdsv3 size page lists sizes from Standard_DC1ds_v3 (1 vCPU, 8 GiB memory, 4 GiB EPC) to Standard_DC48ds_v3 (48 vCPUs, 384 GiB memory, 256 GiB EPC). It also notes these are Generation 2-only VMs that don't support Live Migration, Memory Preserving Updates, Ephemeral OS Disk or nested virtualization.

Microsoft's guide describes the replacements as "lift and shift" options. That needs a caveat. The following comes from general industry knowledge rather than Microsoft's guide: the v6 confidential VMs use a different confidentiality model.

• SGX (DCsv3/DCdsv3) protects specific application code and data inside a hardware enclave. The app has to be written for it, usually with an enclave SDK.
• The v6 confidential VMs protect the entire VM: AMD SEV-SNP on the DCasv6 family and Intel TDX on the DCesv6 family.

An app that splits trusted and untrusted code around an SGX enclave can't be moved onto a TDX or SEV-SNP VM and be expected to keep working the same way. Some teams will find whole-VM confidentiality makes things simpler. Others will have to redo their attestation flows, key release logic and threat model. Either way it's engineering work, not just a SKU change.

Section summary: Moving off SGX is an architecture decision. Plan time for code and attestation changes, not just resizing.

Microsoft's recommended replacements​

The guide groups replacements by workload type and processor vendor:

1. VM-based workloads on AMD: DCasv6/DCadsv6 confidential VMs on AMD's fourth-generation EPYC processors, or memory-optimized ECasv6/ECadsv6.
2. VM-based workloads on Intel: DCesv6/DCedsv6 on Intel 5th Generation Xeon Scalable processors, or memory-optimized ECesv6/ECedsv6.
3. Containerized workloads: Azure Confidential Container Instances (C-ACI), a serverless option for lift-and-shift container apps. For workloads that need orchestration, Virtual nodes on Azure Container Instances (C-VN2) for AKS.

The FAQ puts the overall direction simply: before October 31, 2029, customers should modernize workloads to new generation Confidential Virtual Machines (CVMs) or Azure Confidential Container Instances.

Microsoft says the newer offerings bring better price-performance, wider regional availability, more memory per vCPU and faster SSD storage. These are vendor claims. Benchmark your own workload before you accept them.

Section summary: Choose by workload model first (VM or container), then by vendor and memory needs.

The second migration in a row for SGX customers​

This is the detail that will sting. When Microsoft retired the previous SGX generation, it sent customers to the series now being retired. The DCsv2 retirement guide said: "On June 30, 2026, DCsv2-series virtual machines (VMs) will be retired. Before that date, please migrate your workloads to DCdsv3-series virtual machines." It recommended DCdsv3 to anyone who wanted to continue using the enclave-based offering with Intel SGX technology.

Some customers were still making that move in 2026. In a Microsoft Q&A thread from this spring, one customer described planning to migrate a production server from Standard DC4s_v2 Family vCPUs to Standard_DC4ds_v3 family in the East US region after receiving the DCsv2 retirement notice. Teams that just finished that migration now have another one.

The bigger change is that the new guide doesn't name an SGX-based successor. Every recommendation is either a whole-VM confidential VM or a confidential container service. It's reasonable to read that as Azure ending its general-purpose SGX enclave VM line, though Microsoft hasn't put it that way.

Section summary: Recent DCsv2 migrants face a second move, and this time there's no SGX-to-SGX path.

Practical migration checklist​

Based on Microsoft's guide:

1. Inventory: Find every DCsv3/DCdsv3 VM, scale set, Dedicated Host deployment and SGX-aware AKS workload in all subscriptions.
2. Classify: Separate SGX enclave apps, which need re-engineering, from workloads that only needed encryption in use, which may fit a confidential VM directly.
3. Choose a target: Review each workload's performance and memory needs against the v6 DC/EC families or C-ACI/C-VN2.
4. Check regional availability: If no confidential VM is available in your current region, Microsoft suggests checking nearby regions or contacting Azure Support.
5. Secure quota early: Check that the target series has enough vCPU quota before resizing or migrating, and request more through the Azure portal if you need it.
6. Watch the disk configuration: By Azure naming convention, a "d" in the size name means a local temp disk. The DCsv2 guide notes that you can't resize a VM size that has a local temp disk to a VM size with no local temp disk and vice versa. Account for temp-disk differences when you pick a target.
7. Model costs: Microsoft only says billing might change. It doesn't say whether prices will go up or down, so price your actual target sizes.

Reserved Instances​

If you hold one-year or three-year Reserved Instances on these series, Microsoft's guide suggests reviewing active reservations in the Azure portal and then choosing one of these options:

• Exchange existing reservations for a new VM series without penalties.
• Trade in reservations for an Azure Savings Plan for compute, which works across VM families and regions.
• Buy new reservations for the replacement series. The guide suggests one-year terms if you want flexibility.

Getting help​

The guide points to Microsoft Q&A for community help. Customers with a support plan can open a request from Help + support > Create a support request with these values:

• Issue type: Technical
• Service: My services
• Service type: Virtual Machine running Windows/Linux
• Resource: the affected VM
• Problem type: Assistance with resizing my VM

Then choose the problem subtype that fits, follow the Solutions and Details tabs, and select Review + create.

The bigger picture​

This is one of several VM retirements on Azure's calendar. On the same lifecycle page, Microsoft notes that the Dv3, Dsv3, Ev3, and Esv3 series retire on November 15, 2029, after which customers can't create, resize into, run, or purchase these sizes. Shops running older general-purpose VMs alongside confidential ones will have two deadlines two weeks apart in late 2029. It's sensible to combine both into one modernization plan rather than two separate fire drills.

Confidential computing is also changing direction. Azure is moving from enclaves that protect parts of an app to protection for whole VMs and containers, which makes it easier to protect an existing workload without rewriting it around an enclave. Customers who invested in SGX enclaves will see this as a cost they didn't choose, and that's a fair reading too.

Bottom line: October 31, 2029 is the shutoff date. November 1, 2026 is when Microsoft's subscription restrictions begin. If your apps depend on SGX enclaves, start the re-engineering work early.