Azure & Microsoft migration
What an Azure landing zone actually is (and what it actually costs to stand one up)
The term shows up in almost every migration conversation and almost nobody defines it before using it. Here is the plain-language version, and an honest answer on cost.
This post is part of Azure & Microsoft Migration.
One term, two meanings — this post is about the Azure one
"Landing zone" gets used two different ways in this market, and the overlap causes real confusion. In data engineering, a landing zone is a raw-data staging area — the first place data lands before anything transforms it. In cloud migration, an Azure landing zone is something else entirely: the governed environment your workloads move into. This post is about the second meaning, because that is the one buyers keep hearing in migration conversations and the one nobody quite explains before using the term as if it were obvious.
The plain-language definition
Microsoft's own definition: "an Azure landing zone is a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment." In plainer terms — it is the answer to "before we put anything real in Azure, who can reach what, which network can talk to which, who is billed for it, and what stops someone accidentally exposing a database to the internet on their first afternoon."
Microsoft Learn — What is an Azure landing zone?
A landing zone is not an application, and it is not a single subscription. It is the scaffolding decisions you make once, so that every workload that arrives afterwards inherits the same guardrails instead of reinventing them — or skipping them.
What's actually in one
Stripped to what a buyer actually needs to know, a landing zone answers five questions:
- Identity. Which directory governs who can sign in and what they can do — for us, that is Microsoft Entra ID, with named individual accounts and no shared credentials.
- Network topology. How subscriptions connect to each other and back to your offices — most commonly a hub-and-spoke design, where a central "hub" subscription carries shared connectivity and a "spoke" subscription carries each workload's own network and resources.
- Subscription structure. Which resources sit in a shared "platform" subscription (identity, connectivity, shared management) versus a "workload" subscription that a specific application actually uses.
- Policy guardrails. Rules enforced automatically — allowed regions, allowed resource types, mandatory tagging, encryption defaults — so a guardrail is a setting, not a person remembering to check something on a Friday.
- Monitoring and cost management. Where logs land, who is alerted on what, and how spend is attributed back to the workload that generated it.
The diagram above is the smallest honest version of this: one platform subscription holding identity, the network hub and shared management, one workload subscription holding the application's own network and resources, peered to the hub, with a link back to your offices. A larger estate adds more workload subscriptions and, often, more regions — the shape does not change, only the count.
What it actually costs to stand one up
We are not going to give you a dollar figure here, and you should be careful with anyone who does before seeing your estate — the honest answer depends entirely on scale and on how much governance your business genuinely needs, not on a rate card. What we can give you honestly is the order of magnitude, in effort rather than price.
- A minimal landing zone for a small estate — one or two workload subscriptions, a single region, a straightforward identity model — is realistically an engineer's work of a few days to a couple of weeks, especially starting from Microsoft's own free, open-source landing zone accelerators rather than a blank slate.
- A landing zone built for a genuinely regulated estate — multiple subscriptions, hub-and-spoke networking across regions, policy-as-code guardrails, a full identity and access model with conditional access and logging retention tuned to an audit requirement — is realistically several weeks, and it touches every team that will eventually put a workload behind it, not just the engineer building it.
Microsoft publishes free, infrastructure-as-code accelerators for both halves of a landing zone — the platform foundation and the individual application landing zones — specifically so most organisations don't have to design one from a blank page. Starting from one of those and adapting it is almost always faster and cheaper than a fully bespoke build, and it is the starting point we use ourselves.
Start with the assessment, not the migration.
Book an assessment call30 minuteswith the engineer who would scope the work[PLACEHOLDER: written-summary turnaround, not yet committed]