Why sequence matters
The most common cloud migration failure is not technical. It is arriving at workload number forty and discovering that the first thirty-nine were deployed with inconsistent networking, ad-hoc identity, and no cost attribution — so nobody can say what anything costs or who owns it.
A landing zone front-loads those decisions. It is the set of subscriptions, policies, network topology and identity boundaries that every subsequent workload inherits by default.
The components worth arguing about
Most landing zone designs converge on a similar structure. The parts that genuinely warrant debate in your context are these:
- Management group hierarchy — mirror the organization's accountability model, not its org chart
- Subscription topology — one per workload-and-environment is the defensible default
- Hub-and-spoke networking, and whether the hub is Virtual WAN or self-managed
- Identity boundaries — which workloads share a tenant and which are genuinely isolated
- Policy-as-code from day one, with deny effects rather than audit-only where it matters
- Tagging enforced by policy, because FinOps without tags is guesswork
Getting adoption right
A landing zone nobody uses is shelfware. Ship it with a paved road: a reference pipeline, a working example workload, and documentation an application team can follow without a platform engineer sitting next to them. Then measure adoption and treat low uptake as a product problem, not a compliance one.