Build the landing zone before the app, not after

Every platform migration we get called in to rescue traces back to the same root cause: someone shipped the first workload before the foundation existed. Networking got improvised, identity got copied from a tutorial, and policy showed up later — once three teams had already built on the improvisation. Unwinding that costs far more than doing it in order would have.

Why the order matters

A landing zone isn’t paperwork to clear before the real work starts. It’s the set of decisions — network topology, identity model, subscription boundaries, policy guardrails — that every later workload inherits. Settle them once and hundreds of teams inherit them for free. Leave them unsettled and every team re-decides them on its own, usually worse.

The trap is that the first workload always feels urgent while the foundation always looks like overhead. It isn’t overhead. It’s what makes the second, tenth, and hundredth workload cheap.

A sequence that holds up

Start with identity and network as code. Define subscriptions and management groups that encode your security boundaries. Add policy-as-code so non-compliant resources can’t be created in the first place. Then, and only then, deploy a reference workload through GitOps — and use it to confirm the paved road works before anyone else drives on it.

This is deliberately boring, and that’s the point: keep the platform predictable so the products built on it can be the interesting part.