Most Azure Landing Zones do not fail because the technology is hard. They fail in the first weeks, during scoping, governance decisions, and team alignment, long before the first Subscription is deployed. The platform may look perfect on day one and still be doomed by day thirty.
Here is why that happens, and what you can do about it. Each mode below links to a longer field note in Before You Deploy where a New Zealand programme story expands the point.
1. No Business Context, Just a Reference Architecture
The most common failure mode: a team downloads the ALZ reference implementation, runs terraform apply or the Bicep pipeline, and calls it done.
The ALZ accelerator encodes Microsoft’s recommended defaults, not your organisation’s requirements. Without understanding:
- Who owns budgets and cost accountability?
- What are the regulatory constraints (HIPAA, PCI DSS, GDPR, sovereign cloud)?
- How do teams request access and deploy workloads?
…you are deploying an architecture in search of a problem. Start with the
Cloud Adoption Framework readiness questions before you run the accelerator.| Symptom | What to do instead |
|---|---|
| Six months in, nobody can answer why the management group hierarchy is structured this way. | Run discovery first. Two weeks of workshops saves six months of rework. References: Landing Zones Without Business Context · CAF: Azure landing zones · Azure Well-Architected Framework |
2. Governance Treated as a Blocker, Not an Enabler
Many landing zones are born from a compliance mandate, and it shows. Every policy is a hard deny. Every deployment needs three approvals. Platform teams become the department of “no.” Workload teams do not wait: they buy SaaS, open shadow subscriptions, or escalate until someone grants an exception.
Governance is a product. If nobody wants to consume it, it has failed.
| Symptom | What to do instead |
|---|---|
| Workload teams route around you: shadow subscriptions, personal accounts, or SaaS bought outside the platform. Classic shadow IT . | Start with audit mode , not deny. Ship golden paths so the compliant route is the easiest. Measure time to
deploy a compliant workload, not policy count. References: Governance as a Blocker · CAF: Governance design area · WAF: Security |
3. The Platform Team Builds Alone
A classic anti-pattern: the platform team spends a quarter building the landing zone in isolation, then announces it to the rest of the organisation.
| Symptom | What to do instead |
|---|---|
| The first real workload lands and networking, identity, and CI/CD all conflict with what the platform team shipped. | Onboard one pilot workload team from week one. Ship an MVP of guardrails. Prove a new team can go
from request to a compliant, observable workload in days, not weeks. References: The Platform Team That Built Alone · CAF: Application landing zones · WAF: Operational Excellence |
4. Undefined Subscription Strategy
Landing zone debates die on this hill: one subscription per application? Per environment? Per team? Per cost centre?
| Symptom | What to do instead |
|---|---|
| Teams improvise names and boundaries until you have sprawl, shared environments with no cost attribution, and years of unwind. | Define isolation around blast radius , compliance, billing, and quota.
Document it, automate subscription vending, and enforce tagging. Subscriptions are cheap; wrong
boundaries are not. References: Undefined Subscription Strategy · CAF: Subscription design · CAF: Subscription vending · WAF: Reliability |
5. Network Design Based on Datacentre Thinking
Hub and spoke , ExpressRoute , forced tunnelling , everything in one vNet region. Many landing zones are just a datacentre replica with extra steps.| Symptom | What to do instead |
|---|---|
| The design optimises for on premises hosting. Cloud native workloads pay a latency, cost, and complexity tax they do not need. | Design for where workloads will be, not where they are today. Separate hybrid connectivity from
intra cloud patterns. Write down the trade offs, including why you chose vWAN or did not. References: Datacentre Thinking in a Cloud Landing Zone · CAF: Network topology and connectivity · WAF: Performance Efficiency |
6. No Operating Model Behind the Architecture
The landing zone defines what is deployed. But who runs it? Who responds to policy violations? Who approves exceptions? Who pays?
| Symptom | What to do instead |
|---|---|
| Alerts land in a mailbox nobody watches. Exceptions pile up. The platform team burns out on unbudgeted toil. | Define a RACI before deployment. Budget run costs, not just the build. Put an
exception review process with an SLA in place early. References: The Operating Model · CAF: Management design area · WAF: Operational Excellence |
7. IaC Without Platform Engineering Discipline
The code exists, but there is no pipeline, no environment promotion, no testing, no versioning strategy. Someone’s laptop is the deployment source of truth.
| Symptom | What to do instead |
|---|---|
| Someone's laptop is the source of truth. Configuration drift sets in within a year. | Everything through pipelines from day one. Treat Infrastructure as Code as the
product. Test policy and RBAC changes in a non production management group,
version releases, and communicate breaking changes. References: IaC Without Platform Engineering Discipline · CAF: Platform automation and DevOps · WAF: Operational Excellence |
8. Big Bang Over Incremental Delivery
The “we will launch the landing zone when everything is perfect” approach. Twelve months later, the platform still is not live, business units have moved ahead with their own subscriptions, and the project gets cancelled.
| Symptom | What to do instead |
|---|---|
| Perfection delays launch. Every month increases shadow IT and erodes sponsorship. | Deliver in iterations: core guardrails, identity and networking, vending, advanced policies, then FinOps . Hit a ready for first workload milestone fast, and ship something
valuable every four to six weeks. References: Big Bang Over Incremental Delivery · CAF: Migrate methodology · WAF: Safe deployment practices |
A Quick Self Assessment
Before you start your landing zone initiative, can you answer these?
| Check | Question | Further reading |
|---|---|---|
| ☐ | Do we have documented business and compliance requirements, not just a reference architecture? | Without Business Context |
| ☐ | Is there a named executive sponsor and a funded platform team? | Operating Model |
| ☐ | Do we have a subscription strategy with an owner? | Undefined Subscription Strategy |
| ☐ | Have we talked to at least three workload teams about their needs? | Platform Team Built Alone |
| ☐ | Do we know who operates this platform after launch? | Operating Model |
| ☐ | Is our first workload pilot identified? | Platform Team Built Alone |
| ☐ | Do we have CI/CD for platform changes from day one? | IaC Without Discipline |
If you answered “no” to more than two, the landing zone has not failed yet. But it is on schedule to.
Final Thought
An Azure Landing Zone is not a deployment. It is a product, with users (workload teams), a roadmap, an operating model, and a value proposition: making it easier to build compliant, secure, well architected solutions on Azure than anywhere else.
Teams that treat it as an infrastructure project tend to deliver infrastructure that nobody uses. Teams that treat it as a product tend to deliver a platform the organisation actually adopts.
Design accordingly.
One Block · build from here
Have you seen a landing zone fail before it began? What was the root cause? Leave a note if you want to discuss.