ALZ-Bicep Classic is on a dated path to archival

The deprecation notice comes first for a reason

The repository leads with a notice about the future of ALZ-Bicep Classic, and it is unusually specific about the dates. With Bicep AVM now generally available and set as the default in the ALZ Accelerator for Bicep, the deprecation process for classic ALZ-Bicep has begun.

The table gives three rows. Now, Bicep for Azure Verified Modules for Platform Landing Zone is the default starter module. On February 16th, 2026, the Bicep Classic starter module was removed from the Accelerator. On February 16th, 2027, the ALZ-Bicep repository will be archived.

Between those two dates, the repository is still supported, but the support is described narrowly. The list is bug fixes, security patches and policy refreshes, and the notice adds that this continues for a period of 12 months after that date, meaning after 2026-02-16. After February 16th, 2027, the repository will be archived and no longer supported.

There is a small inconsistency in the notice itself, which is worth noting because it affects how much you trust the rest of the document. The notice says ALZ-Bicep is still supported in the Accelerator as Bicep Classic - Complete, and in the next sentence says this was removed in its entirety on February 16th, 2026. The two statements cannot both be describing the current state.

For an adopter, the practical reading is that this is a project in its final phase. The value of adopting it now is that it is the same code many organisations already run, and the patches keep flowing. The value of starting a new landing zone on it is close to zero, because the successor already exists and is set as the default.

The architecture it implements comes from the Cloud Adoption Framework

The repository provides an approach for deploying and managing the core platform capabilities of the Cloud Adoption Framework Azure Landing Zones conceptual architecture using Bicep. The architecture itself is not invented here. It is the well-known landing zone model, with management groups for platform and workloads, the platform landing zone, the intermediate landing zone for shared services, and the workload landing zones above that.

What the repository contributes is the Bicep expression of that architecture as a set of modules. The topic list names the vocabulary: alz, azure-landing-zones, azure-policy, enterprise-scale, eslz, landing-zone, landing-zones, and bicep.

The design also draws on the Azure Landing Zones Accelerator, which is the tool that stitches the modules together into a deployment. The consumer guide wiki section documents the accelerator alongside the classic accelerator and the Azure Monitor Baseline Alerts for the classic accelerator, so the accelerator is a first-class part of the experience rather than a convenience.

The architectural considerations are documented separately in the Azure Architecture Center, where the project points to a page on Azure landing zones Bicep modules design considerations. That link is a good sign for an adopter, because a design rationale written by the team is more useful than a module list with no explanation of the reasoning behind it.

The wiki index also covers the two network topologies the modules support, hub and spoke, and Virtual WAN, which is the kind of fork in the road that decides how you consume the modules.

Modules deploy one at a time, and that is the constraint

The Overview section is honest about how the deployment works, and the mechanism matters for anyone planning a pipeline.

Each module can be deployed separately via the command line. Future releases were to include a more automated approach using orchestration modules, but the notice states that due to current Bicep and ARM limitations, this is not possible today.

That is the key constraint of the whole project. A landing zone is a graph of subscriptions, management groups, policies and role assignments, and the natural way to deliver one is as a single orchestrated deployment. ALZ-Bicep does not do that. It gives you modules, and the assembly of those modules into a working environment is something you do, which is why the Accelerator exists and why the sample pipelines for GitHub Actions and Azure DevOps are documented in the wiki.

The wiki index shows the shape of the documentation a consumer actually needs. There is a home page, a deployment flow section with separate pages for hub and spoke and for Virtual WAN, a consumer guide, a known issues section, and a frequently asked questions page. There are also two deep dives that tell you what is going on inside the modules: how ALZ-Bicep implements Azure policies, covering both adding custom policy definitions and assigning policies, and how it implements resilient deployments across availability zones.

The policy deep dive is the one to read if you are going to customise anything, because policy assignment is where a landing zone meets the governance requirements of a particular organisation, and the mechanism the modules use is not obvious from the outside.

Getting started means reading the deployment flow, not running a command

There is no single install command in this repository, and the getting started section is honest about that. To get started with ALZ Bicep, the project refers you to the deployment flow wiki page for three things: the prerequisites and dependencies for the overall implementation, the high-level deployment flow, and links to more detailed instructions on individual modules.

So the entry point is documentation rather than a script, which is the right shape for a repository whose output is an Azure environment rather than a package. The prerequisites in particular are not a pip install, they are a set of decisions about management group structure, subscriptions, regions and identity, and the documentation does not attempt to compress them into a bullet list.

For a team that wants a guided path, there is a three-part video series on the Azure Enablement Show. Part one is an introduction to Azure Landing Zones Bicep, part two covers enabling platform services, and part three covers enabling landing zones. Each part is linked.

The other practical detail worth knowing is how the modules are delivered. The wiki has a page on Azure Container Registry deployment with a private Bicep registry, which is the route for organisations that cannot pull modules from a public registry, and there is a page on telemetry tracking using customer usage attribution, described as a PID, which explains how deployment is attributed.

The repository also carries a ps-rule.yaml and a .ps-rule directory at the top level, so the module set is linted with PSRule, the PowerShell rule engine, and the workflow badges show an update-policy workflow running against the main branch, which is the mechanism behind the policy refreshes the deprecation notice promises.

The deployment touches the subscription hierarchy, so review the policy content

Two aspects of this project deserve a careful reading before it is deployed anywhere, and neither is about Bicep.

The first is the Azure Policy content. A landing zone module set is, at heart, a large collection of policy definitions and assignments. What they deny, what they audit, and what they modify depends on the organisation, and the same module set can produce a compliant landing zone in one company and a broken one in another. The wiki's policy deep dive covers adding custom policy definitions and assigning policies, which is where the customisation happens, and the policy refresh workflow means the built-in content changes over time without a version bump. A team that has not read the policy content it is about to enforce will find out in production.

The second is the hierarchy itself. These modules create and modify management groups, subscriptions, role assignments and, as the repository name suggests, policy assignments at the platform and intermediate levels. That is a deployment with wide blast radius by design, and it is not reversible by deleting the resources it created.

The telemetry description is also worth reading rather than skipping. The project states that when you deploy one or more modules from the repository, Microsoft can identify the installation of those modules with the deployed Azure resources, correlate those resources, and collect the information through customer usage attribution, governed by Microsoft's privacy policies. There is a link for turning usage data off, and the wiki page covers it. That is a reasonable arrangement and a documented one, but an organisation with a policy on telemetry should make the decision explicitly rather than by default.

MIT terms, a CLA for contributors, and a repository with a shelf life

The licence is MIT, with a LICENSE file at the top level of the repository, so the code itself carries no copyleft obligation for a commercial deployment.

Contributing is a different matter, and the contribution guide explains it. Most contributions require you to agree to a Contributor License Agreement declaring that you have the right to grant the rights to use your contribution, with a link to the Microsoft Contributor License Agreement page. When you submit a pull request, a CLA bot determines whether you need to provide one and decorates the pull request appropriately, and you only need to do this once across all repositories using that CLA. The project has also adopted the Microsoft Open Source Code of Conduct, and a member of the team triages, reviews and discusses each pull request.

The repository carries SECURITY.md and SUPPORT.md at the top level, which is the expected arrangement for a repository of this kind, and the OpenSSF Scorecard badge gives a pointer to the project's supply chain posture.

Activity is current. The repository is not archived, the last push was on 2026-10-09, and the recent releases are v0.25.6 on 2026-08-24, v0.25.5 on 2026-08-20 and v0.25.4 on 2026-04-29. A patch release on a 0.25 line is what a project in maintenance mode looks like, which is consistent with the deprecation notice.

For an organisation that has to justify a dependency, the honest framing is that this is a dated but maintained dependency with a published end date, and the end date is in the documentation rather than something you have to discover.

Editorial conclusion

ALZ-Bicep suits an organisation already running the classic Azure Landing Zones Bicep modules and wanting to keep patching them until the migration is done, since bug fixes, security patches and policy refreshes continue for twelve months after the classic starter module left the Accelerator. It is the wrong starting point for a greenfield landing zone, because the documentation names Bicep AVM as the default starter module and gives a fixed date for archival. Before you adopt it, read the migration guidance the project points at for moving to Bicep AVM, check the deployment flow wiki page for the prerequisites of the module you need, and confirm whether your organisation's pipeline still references the classic starter module, since that reference was removed on 2026-02-16.

Frequently asked questions

Official sources

1. Azure/ALZ-Bicep on GitHub
2. Issues
3. License: MIT
4. README
5. Releases