Moving Azure Landing Zones to AVM before the CAF Enterprise Scale deadline

If you have been running an Azure platform landing zone on Terraform, the chances are your root module calls terraform-azurerm-caf-enterprise-scale. It did the job: management groups, policies, RBAC, and connectivity — all in one opinionated blob. The trade-off was that it was hard to customise, slow on large tenants, and awkward to split across platform teams.

That module is being archived in August 2026, with no further provider compatibility updates or security fixes after that point. If your landing zone still depends on it, now is the time to plan the move.

What replaces it

Microsoft has shifted to Azure Verified Modules (AVM) — a library of independently versioned, peer-reviewed, Microsoft-maintained Terraform modules. For platform landing zones the four you care about are:

Module	What it manages
Azure/avm-ptn-alz/azurerm	Management groups, Policy, Role Assignments
Azure/avm-ptn-alz-management/azurerm	Log Analytics, automation, operational tooling
Azure/avm-ptn-alz-connectivity-hub-and-spoke-vnet/azurerm	Hub-and-spoke networking
Azure/avm-ptn-alz-connectivity-virtual-wan/azurerm	Virtual WAN connectivity

Each module is published independently on the Terraform Registry. The core avm-ptn-alz module hit version 0.21.0 on 27 May 2026.

The biggest change: AzAPI instead of AzureRM

The new modules use the AzAPI provider as their primary driver. This matters for three reasons.

Speed. AzAPI speaks directly to Azure Resource Manager’s REST API with built-in retry logic for transient errors. Users with large tenants report order-of-magnitude deployment time improvements compared to the old enterprise-scale module.

Day-zero resource support. AzAPI can deploy anything the ARM REST API exposes — even before azurerm ships a typed resource for it. New Azure features reach your module without waiting on a provider release cycle.

Cleaner state footprint. The separate ALZ provider (alz) loads architecture definitions — management group hierarchy, built-in policy sets — independently from the state that tracks real resources. This significantly reduces the blast radius when you upgrade providers.

Provider requirements and a minimal module call

The provider pins have changed. At a minimum you need:

terraform {
  required_version = ">= 1.12, < 2.0"
  required_providers {
    azapi = { source = "Azure/azapi", version = "~> 2.4" }
    alz   = { source = "Azure/alz",   version = "~> 0.21" }
  }
}

A basic call to the core module looks like this:

module "alz" {
  source  = "Azure/avm-ptn-alz/azurerm"
  version = "~> 0.21"

  architecture_name  = "alz"
  location           = "westeurope"
  parent_resource_id = data.azurerm_client_config.current.tenant_id

  # Override a built-in policy parameter
  policy_assignments_to_modify = {
    alzroot = {
      policy_assignments = {
        Deny-Public-IP = {
          parameters = {
            effect = jsonencode({ value = "Deny" })
          }
        }
      }
    }
  }
}

The architecture_name = "alz" argument tells the ALZ provider to resolve the full Microsoft reference architecture definition — management group hierarchy, policy initiatives, and default role assignments — without you having to specify any of it. You customise on top of that baseline rather than rewriting it from scratch.

Two paths to adoption

Accelerator (recommended for most teams)

The Azure Landing Zones IaC Accelerator bootstraps a complete platform in a structured four-phase run: planning, prerequisites, bootstrap, deploy. It composes all four AVM modules, provisions state storage, configures managed identities with OIDC federated credentials, and wires up CI/CD pipelines for either GitHub Actions or Azure DevOps. You answer a configuration questionnaire and walk away with a working deployment pipeline aligned to Microsoft best practices. For teams that want opinionated defaults without stitching the modules together manually, this is the right starting point.

Direct module usage (advanced)

If your organisation has non-standard requirements — custom management group hierarchies, overlay policies from a third-party compliance framework, or split ownership across platform teams — you can consume each AVM module independently in your own root module. The modules are designed to be composed rather than monolithic, which is the structural improvement the enterprise-scale module could never offer.

Practical notes for brownfield migrations

If you are already running caf-enterprise-scale, you are not starting from zero. Your management groups and policies already exist in the tenant; the goal is to import that state into the new module structure rather than destroy and recreate everything.

A few things to sort out before you start:

• Audit your customisations. The old module’s archetype_definitions and custom library folders are not directly portable. Map them to policy_assignments_to_modify blocks and custom architecture definitions in the new module.
• Update your provider pins first. Terraform 1.12 and AzAPI 2.x are hard requirements. If your pipeline pins older versions, that is the first change — test it in a separate workspace before touching the landing zone code.
• The Accelerator is greenfield-only. For an existing deployment you need the advanced path and careful use of terraform import. The migration guidance at azure.github.io/Azure-Landing-Zones/terraform/ is where to start.
• Pilot on a non-production management group scope. Import is non-destructive, but running both module versions against the same tenant simultaneously is not.

Closing takeaway

The archival deadline is real and not far away. The good news is that the new module structure is a genuine improvement — faster, more modular, less entangled with azurerm release cycles — so this is not just a forced migration. If you have a straightforward landing zone, the Accelerator path is probably two or three days of work. Larger or more customised environments will need more planning, but the migration documentation from the Azure Landing Zones team is solid. Start now, before the pressure of “no more provider compatibility” forces your hand.

---

Sources & further reading: Azure Landing Zones — Terraform, Azure/avm-ptn-alz on Terraform Registry, Deploy landing zones with Terraform — Cloud Adoption Framework, IaC Accelerator — Azure Landing Zones, Release of Bicep AVM for Platform Landing Zone.