AKS will start auto-migrating clusters that use deprecated Availability Set (VMAS) node pools to Virtual Machine Scale Sets (VMSS) node pools on September 30, 2026 — and it gives operators a single CLI switch to do it early. That is the blunt operational fact surfaced in AKS release v20260925 (published Sept 25, indexed Oct 1). If you still run VMAS-backed node pools, you need to make decisions this week, not next quarter.
The release states AKS will automatically migrate deprecated Availability Set clusters to VMSS node pools beginning Sept 30, 2026. If you want to control the timing, run the CLI command documented in the release, for example:
az aks update -g <resource-group> -n <cluster-name> --migrate-vmas-to-vmssTwo related points in the same release deserve equal attention: Windows Server 2022 images are unsupported on Kubernetes 1.37 and later, and the release surfaced with just enough notice to matter. The combination — forced migration of legacy node infrastructure plus a hard compatibility break for a common Windows Server baseline — is the real operational squeeze.
Why this matters
Availability Sets have been the legacy path for AKS node pools. Over the years Microsoft pushed customers toward VM Scale Sets (VMSS) and other managed VM options, but plenty of enterprises, especially Windows workloads, stayed on Availability Sets because of private-image workflows, compliance constraints, or long-standing infra automation. An automatic migration changes the surface area of cluster management: different resource IDs, potentially different node naming and IP behavior, and interactions with machine identities and your provisioning scripts.
The release gives you one CLI knob to run the migration proactively, which is the right move. Teams that wait for an automated migration will be in the weakest position because an automated, service-driven migration reduces room for bespoke compatibility work. That said, Microsoft also compressed the runway — this should have been announced earlier with migration dry-runs and richer telemetry hooks.
Windows workloads are the other hard constraint. If your Windows node pools are based on Windows Server 2022, upgrading a cluster control plane to Kubernetes 1.37 or later will not work with those nodes. Practically, that means you must either:
- Replace Windows node pools with a supported OS image before upgrading the control plane to 1.37+, or
- Hold cluster control planes at 1.36.x (or earlier) until you remediate Windows nodes.
Either path is painful at scale. Replacing Windows node pools typically requires new images, reattaching application-level dependencies, and careful testing of CSI, CNI, and Windows-specific taints/tolerations.
What to do now
If you run AKS with VMAS-backed node pools: inventory those clusters and schedule the CLI-driven migration one-by-one. Treat this as a maintenance window — migrations will touch node identities and can change how your infra automation reconciles instances. If you run Windows Server 2022 nodes: pause any plans to move control planes to Kubernetes 1.37+, and start building replacement Windows node pools on a supported OS baseline.
My take: this is overdue housekeeping from Microsoft — removing old primitives is the right long-term call. But the cadence and notice are too aggressive for enterprise shops with slow, audited Windows rollouts. Microsoft gave a tool, not a migration playbook; for many organizations the hard work is in CI/CD, image pipelines, and compatibility testing, not the single CLI flag.
Expect follow-ups. When a cloud provider starts automatically migrating node infrastructure, it signals a willingness to be opinionated about cluster hygiene. That will make life simpler for greenfield users and managed features, but it will also force brownfield shops to accelerate modernization or accept brittle carve-outs. If you're running Windows on AKS, treat Kubernetes 1.37 as a hard stop until you've migrated both node infrastructure and OS images.
A final note: in the October 1 release index this was the only clearly dated AKS artifact in the Sept 29–Oct 6 window; there were no authoritative new Azure AI or security feature announcements in that period. That narrow focus makes this AKS change the defining Azure operational news for the week — and it's the one that will bite teams who treat infra-deprecation notices as background noise.