An Azure landing zone you can actually defend
Most landing‑zone projects fail not on architecture, but on the moment a workload team needs to ship and the platform is in the way. Here’s how we keep them productive.
A platform team’s real job isn’t to design the landing zone. It’s to make sure the next workload team can ship a production service without writing a policy exception. If your “landing zone” doesn’t pass that test, what you’ve actually built is a gatekeeping function.
The pattern we use leans on the Microsoft Cloud Adoption Framework, but ruthlessly trims the parts your team can’t sustain. Three subscription tiers (sandbox, non‑prod, prod). Policies grouped by control objective, not control technology. A documented exception flow that lives in your ticketing system, not a wiki nobody updates.
For most mid‑market organisations the entire baseline — identity, networking, policy, logging, FinOps tagging — fits inside a five‑week engagement, with a usable first workload landing in week three. That cadence is what makes the platform credible to the people who will actually have to live in it.
Found this useful? Start a conversation.