Why?

Landing zones used to mean a one-time CAF blueprint. In 2026 the pressure is different: AI workloads, tighter governance, and module churn from Azure Verified Modules (AVM). If your platform still treats the landing zone as a frozen template, you will fight every new subscription request.

This note is for platform engineers who already have a landing zone and need a practical upgrade path, not a greenfield rewrite.

What?

Three shifts matter:

  1. AVM is the default building block for shared platform services (network, identity, monitoring), not a side experiment.
  2. Policy-as-code guardrails ship with the modules more often than custom initiative sprawl.
  3. AI-ready connectivity and identity (private endpoints, managed identity patterns) are expected day-one, not phase-2.

You still own the orchestration (Terraform/Bicep pipelines, subscription vending). AVM does not replace your platform team; it replaces a pile of bespoke modules you no longer want to maintain.

How?

Step 1: Inventory what you already vend

List the resources every subscription gets today (hub connectivity, DNS, diagnostics, RBAC). Mark each as: keep custom, replace with AVM, or drop.

[screenshot: table or checklist of current landing-zone components vs AVM module candidates]

Step 2: Pin AVM modules deliberately

Pick one domain (start with logging/diagnostics or networking). Pin module versions in your platform repo. Do not float latest in production vending.

[screenshot: Terraform/Bicep module block with explicit AVM version pin]

Step 3: Wire subscription vending to the new module set

Update the vending pipeline so a new subscription pulls the AVM-backed stack. Keep a feature flag or separate product line if you must dual-run old and new for a quarter.

[screenshot: pipeline or workflow step that calls the landing-zone module for a new subscription]

Step 4: Prove guardrails before broad rollout

Deploy one non-prod subscription end-to-end. Confirm diagnostics land in the central workspace, private DNS resolves, and deny policies fire on a known-bad test.

[screenshot: Azure Portal showing a successfully vended subscription with diagnostic settings and policy compliance]

Step 5: Document the delta for app teams

Publish a short internal note: what changed for app teams (identity, networking expectations) and what did not. Reduce surprise tickets.

[screenshot: short internal wiki or PR description summarizing breaking vs non-breaking changes]

If something above is uncertain for your tenant (especially older hub-spoke designs), treat the AVM swap as incremental: one domain per sprint beats a big-bang cutover.

Questions or war stories welcome? Drop a comment.