Microsoft just flipped the calendar on a migration many platform teams have been dreading: AKS release v20260904 lists an automatic migration that will move clusters using Availability Sets (VMAS) to Virtual Machine Scale Sets (VMSS) node pools starting September 30, 2026. If you're still running VMAS node pools, that migration is now a fixed event with a documented control path — and the impact is larger than a simple instance-type change.
This isn't a fuzzy deprecation. The release notes published around v20260904 pair the VMAS→VMSS migration with a Kubernetes 1.37 preview rollout and a set of patch upgrades. The practical pieces you need to know right now:
- The auto-upgrader will begin migrating VMAS clusters to VMSS node pools on Sept 30, 2026.
- Microsoft calls out controls to manage timing (portal, support, and CLI workflows are mentioned in the release notes). In practice, many teams will handle this by creating VMSS node pools, cordoning/draining VMAS node pools, and moving workloads; some tenants can request scheduling or delays through support.
Run these locally to inspect node pools and add a VMSS node pool (example):
# list node pools in a cluster
az aks nodepool list \
--resource-group my-rg \
--cluster-name my-cluster -o table
# add a VMSS-backed node pool (typical migration path is add->migrate workloads->delete old nodepool)
az aks nodepool add \
--resource-group my-rg \
--cluster-name my-cluster \
--name np-vmss \
--node-count 3 \
--node-vm-size Standard_D4s_v3 \
--mode UserThat's the practical control you have: create VMSS node pools and move workloads on your schedule, or work with Microsoft to coordinate the automatic migration. Good for hygiene, bad for surprises.
Why this matters
VMAS node pools are a legacy primitive: they fragment features, complicate rolling upgrades, and limit parity with VMSS-focused tooling (like native autoscaling, instance lifecycle hooks, and newer host protections). For Microsoft, converging on VMSS node pools simplifies feature delivery and reduces the long tail of special-case engineering. For platform teams, the migration is productive if you treat node pools as cattle; it's toxic if you baked bespoke VM extensions, custom images, or hand-tuned placement into cluster lifecycle.
Specific pain points to audit before Sept 30
- Custom VM extensions or provisioning hooks attached to VMAS nodes — they won't always translate to VMSS-backed nodes cleanly.
- Image families and custom images: ensure the images you depend on are available and supported for VMSS node pools.
- Node identity and bootstrapping flows: expect differences in how managed identities and startup tooling run during reprovisioning.
- CI/CD expectations for node replacement timing; auto-migration will incur rolling replacements that can surface flaky readiness probes or PodDisruptionBudget misconfigurations.
Other notable items in v20260904
AKS v20260904 also lists Kubernetes 1.37 as a preview track and surface-level patch rollouts for older supported branches. Community posts in the same window mention AKS workload/AI isolation work, Azure Copilot Troubleshooting Agent reaching GA, and other product updates — but the primary release notes focus on the VMAS→VMSS migration.
The release notes also call out a retirement date for a host-protection offering (OS Guard) on Dec 10, 2026. If your node security posture relied on that specific offering, you need a migration path to an alternative host-protection or Azure-approved OS image before the retirement date.
Opinion: This is the right call — with teeth
Consolidating onto VMSS node pools is overdue. The cloud vendor model of supporting both VMAS and VMSS forever was an invitation to technical debt. Microsoft giving a date and an auto-migration is the blunt instrument platforms need to get teams off antique primitives. That said, it's a real operational change: if your infra repo treats node shapes as durable contracts, this will break things. You have one quarter to test, adapt, and automate your migration path.
Final thought
Treat Sept 30 as a hard deadline on assumptions about node primitives. If you haven't exercised VMSS node pool workflows — custom images, extensions, identity, and PDBs under rolling replacements — the next four months should be all about testing. Microsoft is removing a footgun by forcing the move, but they just handed platform teams a short sprint: either make your workloads resilient to node reprovisioning or get ready to explain why a cloud vendor should keep supporting a legacy model you chose to depend on.