Still on 22H2? Running a stretched cluster? Or sitting on 23H2 hoping it buys you time? This is your wake‑up call — with clear facts and supported directions, not "just wait."

So there are three overlapping issues: 1. You're still on 22H2 (possibly with stretched clusters). 2. You're on 23H2, but haven't moved to 24H2 and risk falling out of support in April 2026. 3. You're using stretched clusters and need to understand what replaces them. This post covers all three — at the support and architecture boundary level.

To keep this grounded:

• Production environments run on hardware validated and supported for Azure Local, deployed in supported configurations.
• There is an active Azure support plan that allows Azure Local technical cases. At minimum, this requires Azure Standard, Professional Direct, or Developer support. The Basic plan is not sufficient.
• The discussion focuses strictly on Azure Local OS and solution versions that Microsoft explicitly documents and supports — namely the transition from 22H2 → 23H2 → 24H2 (26100.xxxx) under the current monthly release model.

If you're running 23H2 OS (25398.xxxx), you're in better shape — but only temporarily. 11.2510 (October 2025) was the final 23H2 solution release. All 23H2 configurations are supported only until April 2026 After April 2026:

• 23H2 receives no monthly updates
• Support cases will require upgrading before troubleshooting continues

Microsoft's generic OS‑upgrade guidance includes this statement: "There is an exception to the preceding recommendation if you are using stretch clusters. Stretch clusters should wait to directly move to version 26100.xxxx (24H2)." This sentence is easy to misread. Context for stretched clusters: You have effectively been on borrowed time. Microsoft accommodated stretched clusters on 23H2 for customers that already implemented them on 22H2, but that accommodation ends when 23H2 support ends in April 2026. In practical terms:

• There is no supported in‑place upgrade path for stretched clusters to 24H2
• After April 2026, stretched clusters are unsupported

Your next supported state must be a non‑stretched 24H2 design, delivered through deployment and migration, not in‑place conversion.

When changing cluster topology, VM type matters.

Plain Hyper‑V VMs

• Managed via Hyper‑V, Windows Admin Center, or SCVMM
• Can be replicated, migrated, backed up, and restored between clusters
• Remain plain Hyper‑V VMs on the destination

Azure Local‑managed VMs

• Created and managed through Azure via the Azure Local solution
• Their Azure identity is tied to a specific Arc Resource Bridge and custom location

If you move or replicate the underlying VM to another cluster:

• It appears there as a plain Hyper‑V VM
• There is currently no supported mechanism to preserve or transfer its Azure Local VM identity across clusters

You can still deploy the Azure Connected Machine (Arc) agent in the guest OS for OS‑level management, but that does not reconstitute it as an Azure Local‑managed VM. This is a design decision, not a migration footnote.

If you're running a stretched cluster

Recognize that stretched clusters are supported only through April 2026. Plan for a non‑stretched 24H2 architecture. Expect this to involve deployment and migration, not conversion.

Azure Local's 22H2 and 23H2 releases are on borrowed time. 22H2 is already out of support, and 23H2 — including stretched clusters — stops receiving security and quality updates after April 2026. Microsoft now operates Azure Local on a monthly release train based on the 24H2 OS (26100.x). To remain supported, environments must move to 24H2 and the current solution train. This transition is also the point at which stretched cluster designs must be replaced with supported non‑stretched architectures, such as rack‑aware clusters for low‑latency single‑site deployments or independent clusters with replication for multi‑site scenarios.