Most organisations treat the Azure Landing Zone as a checkbox. Something to stand up quickly, get auditors off their backs, and move on. In our experience, that approach is one of the most expensive mistakes an enterprise can make — not because the Landing Zone itself costs money to fix, but because everything built on top of it inherits its flaws.

What a Landing Zone actually is

Microsoft defines it as “a scaled and modular environment.” That’s accurate but undersells the point. A Landing Zone is the architectural contract your entire cloud estate is built on. It governs how subscriptions are organised, how identity is enforced, how network traffic flows, how security policies are applied, and how costs are attributed. Get it wrong and you’re not just dealing with a misconfiguration — you’re dealing with a structural problem that compounds with every workload you add.

Think of it like the foundations of a building. You can plaster over cracks, add floors, renovate the interior — but if the foundations are wrong, eventually you’ll feel it.

Where organisations go wrong

The most common failure we see is the rushed Landing Zone. A team is under pressure to get a workload into Azure, so they stand up a basic hub-and-spoke network, add some policies, and declare it done. Six months later they have five application teams all doing things differently, security exceptions piling up, and a cost centre that nobody can explain.

The second most common failure is the over-engineered Landing Zone. Someone reads the Microsoft documentation cover to cover, implements every optional component, and creates something so complex that the platform team spends more time maintaining the architecture than enabling the business.

The right answer sits between these two extremes — and finding it requires understanding what your organisation actually needs, not what a reference architecture says you should have.

The components that genuinely matter

Not everything in the Microsoft Cloud Adoption Framework is equal. In our engagements, the components that have the most downstream impact are:

Management group hierarchy — this determines how Azure Policy is inherited across your subscriptions. Get the hierarchy wrong and you’ll spend months retrofitting policies onto workloads that were never designed to comply with them.

Identity and RBAC design — who can do what, where, and under what conditions. Entra ID integration, Privileged Identity Management, and the principle of least privilege need to be designed in from day one. Retrofitting Zero Trust identity onto an estate where everyone has been given Contributor access “temporarily” is painful and time-consuming.

Network topology — hub-and-spoke versus Virtual WAN, private endpoints, DNS resolution, ExpressRoute or VPN for hybrid connectivity. These decisions have significant cost and security implications that are very hard to reverse once workloads are running.

Defender for Cloud baseline — every subscription should have a consistent security posture from the moment it’s created. The number of times we’ve seen production workloads running without Defender enabled, or with default policies that haven’t been reviewed, is genuinely alarming.

Cost management and tagging — if you can’t attribute spend to a business unit or application on day one, you’ll never be able to do it cleanly. Tagging policies, budgets, and alerts need to be part of the Landing Zone, not an afterthought.

What good looks like

A well-designed Landing Zone is almost invisible. Application teams can onboard quickly, security teams have confidence in the baseline, and finance teams can see where money is going. Platform changes are made once and propagate everywhere through policy. Security exceptions are rare because the defaults are sensible.

It’s also documented. Not in a SharePoint site that nobody reads, but in Infrastructure as Code — Terraform or Bicep — that can be reviewed, version-controlled, and deployed consistently. If your Landing Zone can’t be reproduced from code in under an hour, it’s not a Landing Zone, it’s a configuration that exists on one server and hopes nothing goes wrong.

The cost of getting it wrong

We were brought in by one organisation after they had been running in Azure for two years without a coherent Landing Zone. They had 47 subscriptions with inconsistent naming, no management group hierarchy, three different network topologies, and security policies that contradicted each other. The remediation programme took six months and cost significantly more than a proper Landing Zone would have cost to build in the first place.

The business case for doing it right first time is not complicated.

Our approach

At Xpress Net we design Landing Zones aligned to the Microsoft Cloud Adoption Framework but adapted to the specific context of each client — their existing identity estate, their network requirements, their regulatory obligations, and their internal operating model. We don’t deploy a template and walk away. We build something that your platform team can own, operate, and evolve.

If your organisation is starting its Azure journey, or if you’ve been running in Azure for a while and something feels structurally wrong, we’d be happy to talk.