Azure just put a hard date on an infrastructure migration most platform teams knew was coming: any AKS clusters still using VM Availability Sets (VMAS) will be automatically migrated to VM Scale Set (VMSS) node pools starting September 30, 2026 — and you can force the move now with the explicit CLI control.
If that sentence landed like a small gut-punch, good. Azure exposes a migration control you can run from the Azure CLI or the portal to trigger VMAS→VMSS migration on your schedule; if you do nothing, the auto-upgrader will do it for you after the deadline. That's the right call from a platform hygiene perspective — VMSS is the modern AKS primitive for rolling upgrades, autoscaling and uniformity — but it's overdue and will bite teams that baked assumptions about VMAS into tooling, patching, or IP-addressing schemes.
Why Azure is forcing VMSS (and why you'll care)
VMSS enables features VMAS never could: predictable instance orchestration, integration with node-image pipelines, and a single control-plane contract for scaling and upgrades. Forcing parity across clusters reduces a huge support and security surface for Microsoft and — in theory — for you. But there are practical traps:
- Custom tooling that touches VM identities, managed disk attachments, or VM-level extensions often assumes VMAS semantics. Those scripts will fail silently or worse, corrupt state.
- Network design that depends on fixed VM IPs or node-level NAT quirks will break.
- Spot/low-priority behaviors and scheduling differences may change pod placement and eviction patterns.
Treat this migration like a rolling upgrade of cluster contract: test it in staging, validate DaemonSet behavior and node-affinity workloads, and update any IaaS-level automation that enumerates VMs.
The release also bundles Kubernetes runtime changes worth paying attention to. AKS release notes call out previews for Kubernetes 1.36 and 1.37 and ship patched control-plane and node binaries built with a newer Go runtime to address multiple security issues. In short: you get hardened control-plane and kubelet/CNI binaries without rebuilding cluster images — a meaningful security lift for teams that lag behind minor updates.
There are deprecations to schedule around: the preview enableCustomCATrust node-pool property is slated for deprecation in 2026; if you rely on it, remove the setting or plan to migrate your trust configuration to the supported pattern to avoid scale or certificate update failures. Likewise, some older Azure Linux/OS-guard images are being deprecated in favor of newer, AKS-supported OS images with a planned cutoff in late 2026. Treat these dates as operational constraints and plan accordingly.
The CI/CD and governance flipside
Azure DevOps is also tightening defaults and expanding security signals: recent updates add deeper security overview metrics and integrations (some in private preview) and change hosted pipeline defaults so Linux container jobs no longer mount the host Docker socket by default. That is a simple but overdue hardening: removing /var/run/docker.sock reduces a common lateral-movement vector in CI.
If your pipelines rely on host-docker access, you'll need to adopt buildkit, use explicit Docker-in-Docker images, or move to containerd-friendly workflows. Between the auto-migration and hardened CI defaults, Microsoft is nudging customers toward narrower blast radii and fewer implicit trust boundaries — a helpful move, but one that raises migration costs for legacy automation.
A final note: the Azure Blog's recent AI/architecture guidance emphasizes treating agent orchestration and cost governance as first-class. That ties to the AKS and DevOps changes: standardized node pools and tighter CI defaults make telemetry, cost attribution, and agent-level guardrails far easier to implement consistently.
If you're still running VMAS, stop postponing this. Schedule a migration window, validate networking and node-level tooling, and use the Azure CLI or portal migration controls to manage your own fate. Azure's auto-migration is the right move for platform scale and security — painful for some teams, but preferable to months of brittle, heterogeneous clusters. The real question now is whether teams will use this forced standardization to modernize pipelines and observability, or simply scramble to patch brittle scripts and hope for the best.
Sources
- Release Notes - Azure/AKS (GitHub)
- AKS v20260904: VMAS→VMSS Auto‑Migration Deadline and Kubernetes 1.36 Support
- AKS v20260904: VMAS→VMSS Auto‑Migration Deadline, Kubernetes 1.37 Preview, and Patch Fallout
- What's new in hyperconverged deployments of Azure Local?
- Microsoft Azure Blog
- Azure DevOps Released Features - Microsoft Learn
- Azure Weekly Newsletter Issue 577