Azure Local users running AKS Arc Windows Server 2022 node pools should treat October 31, 2026 as an internal deadline to identify affected resources, assess migration options, test application compatibility, secure change approvals, and clarify contractual responsibilities.
Microsoft’s Azure Advisor retirement recommendations list the Windows Server 2022 SKU on AKS Arc for retirement on that date. Microsoft Learn also states that Azure Local 2603 is the final release to include the Windows Server 2022 VHD, and that Kubernetes 1.34 is the last supported version for it. Windows Server 2022 will not be supported on Kubernetes 1.35 or later.
As of October 12, 2026, official documentation did not establish the exact time the retirement takes effect, whether existing nodes will automatically stop or be deleted, which successor OS SKU applies to each environment, or the migration schedule, downtime, and costs for individual organizations. It would therefore be premature to assume that all systems will stop on October 31—or that existing nodes will continue without action. Organizations should confirm their own circumstances through Azure Advisor, Service Health notifications, and their support channels, and retain the responses as evidence.
Why preparation is urgent
There are only 19 calendar days between October 12 and October 31. Migration is not simply a matter of changing an OS setting. Microsoft’s guidance calls for updating the Dockerfile’s base image, checking application compatibility, and validating the rebuilt containers in a development or test environment.
Replacing a Windows node pool also involves adding a new pool, updating workload configuration and container images, moving Pods, and eventually deleting the old pool. Resource discovery, image rebuilding, testing, capacity planning, approvals, cutover, monitoring, and cleanup should be treated as one change project. Delaying work until the end of October leaves little time to address compatibility problems or capacity shortages.
What the confirmed guidance says
- Retirement date: Azure Advisor lists October 31, 2026, for “Windows Server 2022 SKU on AKS Arc” and provides affected-resource information.
- Final Azure Local release with the VHD: Azure Local 2603.
- Last supported Kubernetes version: 1.34. Windows Server 2022 is not supported on Kubernetes 1.35 or later.
- Azure Advisor checks: The Reliability recommendations, filtered by Service Upgrade and Retirement, can show the retirement date, retiring feature, and impacted resources.
Technical issues to assess
Kubernetes upgrades
Clusters moving to Kubernetes 1.35 or later should not retain Windows Server 2022 nodes if they are to remain within Microsoft’s stated support scope. Inventory clusters with Windows node pools separately from Linux-only clusters.
Record more than cluster names: include subscriptions, resource groups, Azure Local and Kubernetes versions, each node pool’s OS SKU and node count, Windows workloads, and the responsible teams and business owners.
Container images and application compatibility
The migration may require updating Dockerfiles, rebuilding images, and validating them. Infrastructure teams will need to coordinate with application developers, image vendors, and container registry administrators.
Test at least application startup, authentication, file access, networking, persistent volumes, backups, monitoring, jobs, and performance. Pay particular attention to applications that depend on OS-specific DLLs, fonts, cipher suites, Windows APIs, or service accounts.
Node-pool replacement and workload movement
Microsoft’s procedure involves creating a new Windows node pool, updating the workload’s node selector and container image, applying the configuration, and moving Pods to the new nodes. The old pool should be removed only after the new environment has been validated.
Plan for replica counts, PodDisruptionBudgets, startup times, session persistence, queue processing, batch-job recovery, health probes, and rollback criteria. A rolling update does not guarantee zero downtime; applications with a single replica or external state may affect users during the change.
Environments using gMSA
Microsoft notes that Windows node pools in Azure Local 23H2 and 24H2 do not support gMSA authentication. Windows containers requiring Kerberos or NTLM may encounter anonymous-logon errors. Microsoft identifies AKS on Azure, which supports gMSA, as an alternative.
Organizations using Active Directory integration should therefore assess authentication dependencies and destination support separately. Changing the OS SKU alone may not address the issue.
Contract, compliance, and evidence
Distinguish technical operation from support status
Existing nodes might continue to run after the deadline, but that is different from being supported by Microsoft. The reviewed documentation did not confirm automatic shutdown or deletion on October 31, while it did state the limits on the Windows Server 2022 VHD and Kubernetes compatibility.
Review contracts and service-level arrangements for commitments concerning supported versions, security updates, bug fixes, support access, and failure handling. If an outsourcing agreement requires vendors to maintain supported versions, determine whether exceeding the deadline triggers a reporting or remediation obligation.
Apply change-management controls
The change may affect node pools, images, Deployment YAML, monitoring, backups, networking, and authentication. Change requests should identify affected resources, business impact, test results, the planned switchover, approvers, rollback conditions, and criteria for deleting old nodes.
Before deleting the old pool, verify the new environment, preserve logs and configuration exports, and confirm how to recover if the migration fails.
Recheck personal-data responsibilities when arrangements change
The Personal Information Protection Commission’s FAQ Q7-53 uses whether a cloud provider handles personal data as a factor in assessing whether an arrangement constitutes third-party provision or outsourcing. Its examples include contractual terms prohibiting handling and appropriate access controls.
An OS change alone does not establish that the legal assessment changes. However, if the migration changes the operating entity, support access, data location, or subcontractors, organizations should confirm whether the underlying facts and responsibilities remain the same.
Keep a clear evidence trail
Retain:
- Azure Advisor’s affected-resource list and the date and time it was collected
- Microsoft Service Health notices and other notifications
- Cluster, node-pool, OS SKU, and Kubernetes-version records before and after migration
- Dockerfiles, image tags and digests, and vulnerability scan results
- Test plans, results, and business acceptance records
- Change requests, approvals, work logs, and monitoring results
- Questions sent to support and the responses received
- Approval and execution records for deleting the old node pool
Evidence should document not only what was done, but also how the scope was checked for omissions and who is responsible for resolving outstanding questions.
Actions to take now
IT teams
- Export the affected resources for the Windows Server 2022 SKU on AKS Arc from Azure Advisor.
- Use
az aksarc listto collect node-pool details, including OS SKU and Azure Local and Kubernetes versions. - Map Windows Pods to their images, Dockerfile base images, and node selectors.
- Confirm the applicable successor OS SKU and service terms through the Azure portal or support channels where documentation is insufficient.
- Test the new node pool, images, authentication, networking, storage, and monitoring outside production.
- Set production capacity, replica counts, acceptable downtime, and rollback conditions.
- After migration, verify Pod placement, error rates, throughput, response times, and log integrity.
- Delete the old node pool only after validation, approval, and evidence collection.
Legal and contract teams
- Review Microsoft, reseller, and managed-service-provider agreements for supported-version commitments, notifications, change controls, and additional-cost allocation.
- Confirm internal reporting, customer-notification, and provider-contact requirements if service is interrupted or performance degrades.
- For systems processing personal data, compare operating entities, access rights, data locations, subcontracting, and support access before and after migration.
- Set retention and storage requirements for change requests, test records, support responses, and approvals.
- Track unresolved questions with named owners and deadlines.
The key confirmed facts are the October 31, 2026, retirement listing, Azure Local 2603 as the final release with the Windows Server 2022 VHD, and Kubernetes 1.34 as the final supported version. Claims that existing nodes will stop on the deadline, that a particular OS SKU is guaranteed to be the successor, or that migration will be downtime-free require confirmation for the organization’s own environment. Keep tenant-specific notices, support responses, and validation results alongside the migration plan.