Gustavo Britto

Sovereign CloudOctober 2026 · Gustavo Britto

The Sovereign Landing Zone Accelerator Just Adopted Built-In Policy — on a Repo Microsoft Says It's Archiving

v1.1.0 of the Sovereign Landing Zone accelerator did exactly what the Cloud Adoption Framework has been telling every Azure landing zone team to do: drop the custom copy of its policy initiatives and assign Azure Policy's built-in ones instead. The repository that shipped this improvement carries its own banner: archived in the first half of 2026 — a window that, as of this writing, has already closed.

Two things are true about github.com/Azure/sovereign-landing-zone at the same time, and neither one is a small detail. It's the official Microsoft Cloud for Sovereignty infrastructure-as-code accelerator for the Sovereign Landing Zone (SLZ) — the Bicep and Terraform implementation referenced throughout Microsoft's own sovereignty documentation. And its README and repository description both say, verbatim: "This repo will be archived in the first half of 2026!" An "Important" banner on the same page points readers instead to Microsoft Learn for "the latest Sovereign landing zone reference architecture, guidance, and implementation tooling."

What v1.1.0 actually changed

The repo's v1.1.0 release notes are a genuinely good piece of platform engineering, read on their own:

  • Added — SLZ now assigns Azure Policy's built-in Sovereignty Baseline Policy Initiatives, so policy updates stop depending on a new SLZ release. It also added the ability to assign existing initiatives at scopes other than the top level, assign initiatives that take parameters, and set enforcement mode through a new parPolicyAssignmentEnforcementMode parameter.
  • Removed — SLZ's own copy of the Sovereignty Baseline Policy Initiatives. Existing deployments need manual cleanup steps, documented separately, to remove the old custom copies.
  • Fixed — two "short-term workaround" fixes for cases where NSGs/UDRs and Azure Firewall Policies were being removed or reset by the accelerator, sometimes causing deployments to fail outright, plus a URI-encoding bug in the deployment output links.

This is exactly the move the Cloud Adoption Framework's own guide to migrating landing zone policies (last updated 2025-12-19) recommends for every Azure landing zone: stop maintaining a custom copy of a policy definition once a built-in equivalent exists, because "over time, ALZ custom policies and initiatives can be deprecated or superseded by Azure built-in policies." SLZ v1.1.0 is that recommendation, applied to the sovereignty-specific fork of the landing zone pattern. The CAF guide itself never mentions Sovereign Landing Zone, sovereignty, or Azure Local by name — it's written for the general Azure Landing Zone audience — so there's no official line connecting the general playbook to the specific repo that just followed it.

The part that doesn't add up yet

"First half of 2026" ends June 30. I'm writing this in October, and the repository is still live: the Releases section still lists v1.1.0 as the latest tag, the main branch shows six commits past it that have never been cut into a release, and nothing on the page I could find explains why the archival banner — which reads as a firm, dated commitment — hasn't been acted on roughly a quarter past its own deadline. Either the archival got pushed back without the banner being updated, or "first half of 2026" was never meant as literally as it reads. Both are plausible; neither is stated anywhere on the repo.

What this means practically: if you have a Sovereign Landing Zone deployment built from this repo, you're currently depending on a GitHub repository that (a) just shipped a meaningfully better release, (b) says it's being retired, and (c) is still receiving unreleased commits on main past its own stated retirement window. That's not a reason to panic about an imminent dead end — six unreleased commits suggest active work, not abandonment — but it is a reason to track the "Important" banner's pointer to Microsoft Learn and confirm, before your next deployment, whether the documented replacement tooling actually covers what this repo's Bicep and Terraform templates cover today.

What's not answered yet

  • No updated archival date. The banner still says "first half of 2026" with no amendment, despite that window having passed.
  • No public roadmap for what replaces the repo's Bicep and Terraform implementations. The banner points to Microsoft Learn's sovereignty documentation generally, not to a specific successor repository or module.
  • No migration guide for existing SLZ deployments built from this repo, beyond the manual steps for removing the old custom policy initiatives that v1.1.0 itself requires.

Who should care

If you maintain a Sovereign Landing Zone deployment, pull v1.1.0's policy changes now — the built-in-initiative move is a real maintainability win on its own — but don't treat this repository as a long-term dependency without a confirmed answer on what, if anything, formally replaces it. I'd also connect this to the CAF workload landing zone rename I covered recently: that's a second example this autumn of Sovereign Landing Zone's documentation and tooling lagging a step behind changes happening in the broader Azure Landing Zone ecosystem it's built on.

I'll follow up the moment the repo either gets archived or the banner changes. If you're running production workloads on this accelerator, subscribe to Sovereign Cloud Watch or find me on LinkedIn.

← All articles Subscribe to the newsletter →