Azure just moved the migration needle on a problem platform teams have quietly deferred for years: starting September 30, 2026, AKS is rolling an automatic migration path for clusters still using deprecated VM Availability Sets (VMAS) to modern VMSS-backed node pools. That capability is surfaced in the v2026-09-04 release, which means this is now operational work you have to schedule, not a theoretical deprecation notice.
This matters because VMAS-backed node pools are the last major legacy surface in many AKS estates. Microsoft is doing the right thing: standardizing on VMSS-backed node pools reduces special-case code in cluster lifecycles and enables better node management. But it will bite teams that rely on VMAS quirks — host-affinity, odd disk layouts, or bespoke upgrade automation. Treat this like a node-pool migration: test in staging, snapshot node images/data, and validate CNI and storage attachments before you let the migration touch production.
If you want to run the migration yourself rather than wait, the supported operational pattern today is to add a VMSS-backed node pool, migrate workloads, then delete the legacy VMAS pool. A minimal, realistic workflow looks like this:
# add a VMSS-backed node pool (example)
az aks nodepool add \
--resource-group my-rg \
--cluster-name my-aks-cluster \
--name np-vmss \
--node-count 3
# cordon and drain old nodes as you migrate workloads
kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-local-data
# after workloads are migrated and validated, delete the legacy VMAS pool
az aks nodepool delete --resource-group my-rg --cluster-name my-aks-cluster --name my-legacy-poolDo not treat that as a no-op. The migration changes how AKS manages nodes, and you should validate kubelet configs, VM extensions, and any scripts that reference VMSS instance IDs or availability-set semantics.
A second operational footgun landed in the same release: the preview custom CA trust mechanism (previously enabled via preview flags) is deprecated effective September 14, 2026. If your clusters relied on preview flags or custom preview workflows to change platform CA-trust behavior, remove those preview flags and migrate to the supported certificate-management approach now; continuing to rely on the preview mechanism can cause scaling and certificate-update failures.
The release also promotes Kubernetes 1.37 to preview on AKS and publishes patches for supported 1.36, 1.35, and 1.34 branches. The 1.37 preview brings upstream changes (see also kubelet-in-user-namespace and other 1.37 items covered elsewhere), but the immediate operational items are the deprecations and lifecycle fixes above.
Azure DevOps: pipeline hardening and better security telemetry
On the DevOps side, Microsoft shipped several security and governance features that change CI/CD assumptions. Highlights include project-level billing for AI-assisted features, new malware and security telemetry views in preview, a GitHub Copilot app plugin for Azure DevOps scenarios, and — most likely to break existing pipelines — Linux container jobs no longer get the host's Docker socket mounted by default.
Removing automatic docker.sock mounts is the right call. Mounting chronically privileged host sockets into build containers is the quickest way to escalate CI privileges into your build host. But this will break a lot of existing build logic that expects Docker-in-Docker or a host-mounted docker.sock. If your pipelines rely on docker CLI access, switch to one of these approaches now: run a DinD service container with explicit privileged configuration, migrate to buildah/podman inside the container without host-socket dependencies, or use Microsoft-hosted runners that expose a supported build service. There will be friction; plan it.
Azure DevOps Server also received security patches this month — self-hosted instances should apply the updates. Microsoft continues to fold DevOps security visibility into the GitHub ecosystem; the Copilot app plugin and integrated malware telemetry are part of that alignment.
Architecture signals: AI inference and node management
The Azure Architecture Center updates are more than doc churn: there's new guidance for AI inferencing with virtual SAN options, revised node and node-pool management patterns, microservices patterns for Azure Container Apps + Dapr, and a refined baseline for Foundry-style architectures. These are practical pattern-level changes that reinforce Microsoft's push: run managed VMSS node pools, strengthen runtime isolation, and treat AI inference like stateful infrastructure that needs SAN-level considerations.
Opinion: Microsoft is forcing a cleaner AKS future and the short-term pain is on you — not them. The automatic-migration capability and the preview deprecations are overdue; letting legacy VMAS linger was creating operational debt. Likewise, DevOps pipeline hardening is a necessary breakage. Teams that keep habitually mounting docker.sock or delaying node-pool modernization are going to feel this sharply.
If you manage AKS at scale, block time this week: test the add-nodepool -> migrate -> delete-nodepool workflow in staging, remove any preview custom-CA-trust flags from automation before Sept 14, and audit pipelines for docker.sock dependencies. This is one of those platform housekeeping moments where a few deliberate hours now will save you a chaotic incident later.