Before you design anything, you have to be honest about where you are standing, because the starting point decides more about the engagement than any technical preference will. I have walked into the same conversation enough times to know it sorts into three cases, and knowing which one you are in tells you what to build first, what to leave alone, and what to be afraid of. Get this wrong and you spend the first month solving problems the customer does not have while the real ones sit untouched.
The cleanest case: Microsoft 365 and nothing else
The first case is the organization that lives entirely in Microsoft 365. Exchange Online, SharePoint, Teams, probably Intune, identity in Entra, and no Azure subscription doing any real work. These customers will tell you they are not in Azure. They are wrong, and the misunderstanding is worth correcting gently, because Entra is Azure’s identity plane and it is already the backbone of everything they do. What they mean is that they have no infrastructure in Azure yet, and that is true. It also makes them the easiest possible starting point. There is nothing to migrate, nothing built without a plan, no accidental subscription to unwind. You design the foundation correctly and deploy into a clean tenant. When one of these customers decides to stand up their first workload, whether that is a file server, a Cloud PC pool, or a line-of-business app, the question is never “how do we retrofit governance,” it is simply “which resource group does this land in.” That is the position everyone else wishes they were in.
The common case: Microsoft 365 with accidental infrastructure
The second case is the one you will actually meet, over and over. The organization has Microsoft 365, and at some point somebody needed a server, so they opened the portal, created a pay-as-you-go subscription, and stood up a virtual machine. Then another. Maybe a site-to-site VPN followed, configured once and never documented. Role assignments went straight to individual people because that was the fastest way to unblock whoever was waiting. There is no central logging, the Secure Score is a number nobody has looked at, and the resource groups are named after whatever the person was thinking that afternoon. Often the admin who built all of this has since moved on, and what remains is an environment nobody fully understands and nobody wants to own.
I want to be careful about how I describe this, because the instinct is to call it a mess and the customer can hear the judgment. It is not a mess in the sense of incompetence. It was built without a plan, which is a different thing. Every individual decision was reasonable in the moment. Someone needed a machine and they made one. The problem is that a hundred locally reasonable decisions with no governing structure do not add up to a governed environment, they add up to sprawl. The foundation is the structure that should have been there from the start, and the work here is not to bulldoze what exists but to build the correct structure alongside it and migrate the existing resources in deliberately. That migration is where most of the care goes, and it is why the discovery that precedes it matters so much. You cannot safely move what you have not first understood, which is the subject of the companion to this article.
The demanding case: hybrid, with intent
The third case is the hybrid organization that is deliberately moving to the cloud and has not finished. There is on-premises infrastructure that still matters: domain controllers, file servers, a line-of-business application or two, maybe a database. Entra Connect is almost certainly running, synchronizing identity from the on-premises directory. There is very likely a site-to-site VPN already in place, terminating on a Fortinet or Palo Alto appliance in the office. And critically, there is intent. Someone has decided the direction is toward the cloud, and the foundation you build has to serve not just where they are today but the whole arc of where they are going.
This is the demanding case because the network design carries the most weight and the decisions are the hardest to reverse. It is also the case I use as the running example through the rest of this series, because it is the most common real engagement and because a foundation that handles hybrid correctly handles the other two cases with room to spare. When I need a concrete organization to point at, I will call it Northfork Supply Co.: on-premises Active Directory, a couple of file and application servers, a site-to-site VPN, Business Premium licensing, an external managed detection provider watching the estate, and a stated plan to move toward the cloud over the next couple of years. Everywhere a decision would differ for the Microsoft 365-only reader, I will say so.
The journey the foundation has to survive
The reason the hybrid case sets the design is that hybrid is not a destination, it is a phase, and the foundation has to carry the organization through all of them without a rebuild at each transition. There are three phases, and they blur into each other rather than switching cleanly.
In the first phase the on-premises datacenter is still primary and Azure is an extension of it. The domain controllers live in the office, Entra Connect synchronizes identity outward, and the Azure virtual machines that exist are domain-joined back across the VPN. Traffic flows from Azure toward on-premises because that is where the authority still lives. In the second phase the balance tips. Most workloads have moved to Azure, the domain controllers may now run as Azure virtual machines with the on-premises copies reduced or gone, and the VPN is still up but the traffic across it has reversed. Azure is primary and on-premises is the remnant. In the third phase the datacenter shrinks toward nothing, and a question surfaces that the organization could not have asked at the start: why are users still tunneling into a physical building to reach resources that no longer live there. That question is the signal that the network edge itself needs to change, from a VPN back to an office toward cloud-delivered connectivity, and a foundation designed only for phase one cannot answer it without being torn up.
The whole point of designing the foundation deliberately is that these transitions become configuration changes rather than reconstructions. The address space is planned for where the organization is going, not just where it is. The management group hierarchy has room for platform subscriptions that do not exist yet. The identity model assumes privilege will be reduced over time, not expanded. None of that costs anything at the start, and all of it is expensive to retrofit later, which is the recurring lesson of this entire series. You are not building for today’s environment. You are building the thing today’s environment will grow into.
So the first real task is not technical at all. It is to place yourself honestly in one of these three cases, and if you are hybrid, to be clear-eyed about which phase of the journey you are actually in. That placement decides everything downstream. Once you know where you are standing, the next thing is to find out exactly what is already there, because in the accidental-infrastructure and hybrid cases the environment is holding surprises, and the most expensive ones are the quiet kind that do not announce themselves until a private endpoint fails to resolve months later. Finding them before you deploy is the discovery pass, and it is where the build actually begins.
Azure Landing Zones
‹ Previous: [LZ 1] Azure Landing Zones: The Foundation You Pour Before the House
Next: [LZ 2.1] Discovery Before You Deploy Anything ›
