What a first platform landing zone needs on day one, what can safely wait, and how to grow it without redesigning later.
From Azure Landing Zones (Ultra Transcenders: Beyond the Exam) by Tony Rough (coming December 2026)
The most practical guidance on landing zone scope comes from Microsoft’s migration documentation, which names the failure mode and the smallest useful platform.
The minimum viable platform landing zone is defined in the Azure migration guidance for on-premises experts as the foundation needed to land and operate the first workload. That guidance opens with the failure mode: spending months or years designing, engineering and refining the landing zone without meaningfully migrating any workloads. Its alternative is to assemble a minimal landing zone that is secure, accessible and correctly governed from modular pieces, and to add more pieces only when workloads require them. The minimum consists of:
Spoke virtual networks, workload-specific network security groups and per-workload role assignments are handled in each workload’s migration, not in the platform minimum. The guidance also asks you to build the foundation from repeatable definitions in Bicep, Terraform or another approved method rather than manual portal changes, so that landing zone changes are reviewable.
The same article keeps each piece deliberately narrow:
| Capability | Minimum Learn describes | What can wait |
|---|---|---|
| Baseline policy | Deny unmanaged public internet exposure; require diagnostic settings that feed central logging; steer deployments to regions where the platform is ready; allowed-locations policy from the start if residency or sovereignty applies | Broader policy sets as workloads surface requirements |
| Cost governance | Budgets and alerts at management group or subscription level, with an owner | A perfect tagging or chargeback model, which shouldn’t delay the management group build |
| Connectivity | A working hub with an approved, consistent pattern for workload virtual networks; VPN Gateway or ExpressRoute chosen on throughput, latency, compliance, lead time and routing complexity | The full hub-and-spoke versus Virtual WAN design |
| Identity | Administrative access through Microsoft Entra ID groups with an emergency access path; a workload identity pattern; domain services in Azure only if a workload depends on them | Synchronisation for workloads that don’t need it |
| Shared services | Central logging, baseline monitoring and alert routing, patching and vulnerability scanning ownership, platform DNS design | Deeper backup standardisation, advanced dashboards, retirement of legacy tools |
The article singles out connectivity as one of the few prerequisites that can block every workload at once: management groups and policy can be adjusted after migration starts, but a workload migrated before connectivity is stable might be unreachable. It notes that ExpressRoute delivery depends on the provider and procurement, to be planned in weeks or months rather than days, with VPN Gateway in parallel if dates can’t wait. It calls forced tunnelling generally an antipattern for migrated workloads, to be reserved for workloads with an explicit compliance or inspection requirement. The network chapters own those decisions.
The guidance distinguishes three starting points. A new platform is built from scratch in sequence. A partial platform, often the result of shadow IT with fragmented subscriptions, overlapping address spaces and partial policy, needs remediation rather than a rebuild. A mature platform needs validation that its controls match the incoming workloads. For partial and mature platforms, start with the readiness checks: connectivity, DNS and routing, ingress and segmentation, policy and governance, administrative access, monitoring, capacity, resiliency, subscription hand-over and a workload-like dependency test. Learn is explicit that these checks are a minimum, not a full design review, and points to the Azure Landing Zone Review assessment for platform design validation.
Common pitfall: Spending months perfecting the design with nothing landed - Learn names this as a failure mode and recommends a minimal, correctly governed platform built from modular pieces, extended only when workloads need more; set a date for the first workload and design to that.
Common pitfall: Creating one virtual network with one subnet and placing everything in it to save time - Learn calls this out as a pattern to avoid because contention and weak segmentation appear quickly when all resources share the same boundary.
This note is one section of Azure Landing Zones: Building an Azure Foundation with the Cloud Adoption Framework, an independent guide in the Ultra Transcenders Beyond the Exam series, with comparison tables, diagrams, the common pitfalls and tested companion code, plus a glossary linked to Microsoft Learn.
Due on Amazon in December 2026, in Kindle and paperback editions.
About the book · Azure Landing Zones terms in the glossary · All free notes from Azure Landing Zones
The four environment and four compliance design areas of the Cloud Adoption Framework, what each one decides, and which team usually owns it.
The intermediate root, Platform, Landing zones, Sandboxes and Decommissioned groups: what each is for and why the hierarchy stays shallow.
What each Azure Firewall tier adds, where Basic stops being enough, and how to choose for a hub that many workloads share.
The factors that decide between a customer-managed hub and Azure Virtual WAN, and the constraints that can make the choice for you.
How central private DNS zones and DeployIfNotExists policy register private endpoint records automatically, and the permissions it needs.
When to use Audit, Deny, DeployIfNotExists, Modify and DenyAction in a landing zone, and what each commits you to.
How the two infrastructure-as-code options compare for deploying and running an Azure landing zone, and what decides the choice.