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.
Pilot for the Azure Landing Zones — Failure Modes series. Each section below has a deeper field note tuned for New Zealand organisations. Browse the series overview for every part.
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.Six months in, nobody can answer "why is this management group hierarchy structured this way?"
Run a proper discovery phase. The Cloud Adoption Framework readiness and strategy assessments exist for a reason. Two weeks of workshops saves six months of rework.
Deep dive: Landing zones without business context
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 route around you. Shadow subscriptions via the enterprise agreement, resources deployed through personal accounts, or worse, the business buys a SaaS product instead — classic shadow IT .
- Start with audit mode policies, not deny. Observe real behaviour for a sprint or two.
- Provide golden paths (supported pipelines, approved patterns) so the compliant route is also the easiest.
- Measure governance by time to deploy for a compliant workload, not by number of policies enforced.
Governance is a product. If nobody wants to consume it, it has failed.
Deep dive: Governance as a blocker
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.
The first real workload lands and everything falls apart. Networking does not fit the app's latency requirements. The identity model breaks the CI/CD pipeline. The dev team's deployment process conflicts with policy assignments.
- Onboard one pilot workload team as a design partner from week one.
- Treat the landing zone as an MVP: the smallest viable set of guardrails, iterated on feedback.
- Run a "hello world" test: can a new team go from request to a deployed, compliant, observable workload in days, not weeks?
Deep dive: The platform team that built alone
4. Undefined Subscription Strategy
Landing zone debates die on this hill: one subscription per application? Per environment? Per team? Per cost centre?
Without a clear, documented subscription strategy, teams improvise. You end up with prod-app1-final-v2 subscriptions, shared dev environments with no cost attribution, and a
subscription sprawl problem that takes years to unwind.
- Define your strategy around isolation boundaries: which workloads need separation for blast radius , compliance, billing, or quota?
- Codify it: document the decision, automate subscription vending (what that means ), and enforce tagging for cost allocation.
- Remember: subscriptions are cheap. Rigid, wrong boundaries are expensive.
Deep dive: Undefined subscription strategy
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.This design optimises for a world where workloads live on premises and Azure is a hosting facility. But if your strategy is cloud native, you have paid a latency, cost, and complexity tax for capabilities you do not need.
- Design the network for where workloads will actually be, not where they are today.
- Separate decisions: hybrid connectivity needs versus intra cloud traffic patterns.
- Document the trade-offs explicitly. "We chose vWAN because of X" ages much better than "that is how we have always done it."
Deep dive: Datacentre thinking in a cloud landing zone
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?
Architecture without an operating model produces an orphaned platform. Alerts go to a shared mailbox nobody watches. Policy exceptions accumulate with no review. The platform team burns out doing manual toil that was never budgeted for.
- Define a RACI for platform operations before deployment, not after the first incident.
- Budget for run costs: staffing, tooling, ongoing platform engineering, not just the initial build.
- Establish an exception review process with SLA, or exceptions will be granted via escalation.
There is no dedicated Failure Modes deep dive for this theme. The Survived series picks it up as narrative in The Operating Model.
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.
Landing zones change constantly: policy updates, new management groups, network changes. Without CI/CD and proper source control discipline, configuration drift creeps in, and within a year your landing zone code no longer reflects reality.
- Everything through pipelines from day one, including the initial deployment — treat Infrastructure as Code as the product, not a side project.
- Test policy and RBAC changes in a non production management group first.
- Version your platform releases and communicate breaking changes like a platform engineering team would.
Deep dive: IaC without platform engineering discipline
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.
Perfection is the enemy of adoption. Every month of delay increases shadow IT and erodes sponsorship.
- Deliver in iterations: core guardrails, then identity and networking, then vending automation, then advanced policies, then FinOps tooling.
- Define a "ready for first workload" milestone and hit it fast.
- Ship something valuable every four to six weeks.
Deep dive: Big bang over incremental delivery
A Quick Self Assessment
Before you start your landing zone initiative, can you answer these?
| Check | Question | Deep dive |
|---|---|---|
| ☐ | Do we have documented business and compliance requirements, not just a reference architecture? | Business context |
| ☐ | Is there a named executive sponsor and a funded platform team? | This overview (section 6) |
| ☐ | Do we have a subscription strategy with an owner? | Subscription strategy |
| ☐ | Have we talked to at least three workload teams about their needs? | Pilot partnership |
| ☐ | Do we know who operates this platform after launch? | This overview (section 6) |
| ☐ | Is our first workload pilot identified? | Pilot partnership |
| ☐ | Do we have CI/CD for platform changes from day one? | IaC 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.