Most Azure landing zone engagements I run start the same way: a management group hierarchy on a whiteboard, a connectivity subscription, an identity subscription, a handful of landing zones underneath. The reference architecture takes an afternoon to sketch. The part that actually determines whether the migration finishes is never on that whiteboard: who owns policy assignments six months from now, and who pays for the workload that lands in the wrong subscription.
The architecture was never the constraint
Partners and internal platform teams tend to treat the landing zone as a technical deliverable: get the subscriptions provisioned, get the network peered, get the policies applied, hand over the keys. That part of the work is genuinely tractable. What stalls is everything downstream of “who is accountable for this once my engagement ends.”
Three questions decide whether a landing zone survives contact with real workloads:
- Who has the authority to approve a policy exception, and how fast can that approval happen without becoming a bottleneck for every application team?
- Which subscription absorbs the cost of a shared service, and does that allocation model hold up once FinOps starts asking for chargeback by business unit?
- Who owns the RBAC model when the platform team that built it moves on to the next project?
None of these are Azure Resource Manager problems. They are organizational design problems that happen to be expressed through Azure Resource Manager.
Governance debt compounds faster than technical debt
A landing zone with a slightly wrong network topology is an inconvenience. A landing zone with no clear policy exception process becomes, within a year, a landing zone where every application team has learned to route around governance rather than through it. That is the actual failure mode: not a broken deployment, but a working deployment that nobody trusts enough to use as designed.
By the time I get called in to unwind that, the fix is rarely “redo the architecture.” It is closer to renegotiating who owns what, with the technical changes following from that agreement rather than the other way around.
What I sequence differently
On engagements that hold up, the governance model gets designed and agreed before the first subscription is provisioned, not retrofitted after. That means naming the policy owner, the exception process and the cost allocation model in the same working session as the network diagram, and treating disagreement about any of those three as a blocker worth resolving before deployment starts.
It is slower in week one. It is the difference between a landing zone that is still the way of working two years later, and one that has quietly been abandoned in favor of whatever each team decided on its own.