Your First 30 Days With an Azure Landing Zone Partner

A good first month with an Azure landing zone partner produces four things: the decisions that are hardest to reverse settled in writing, a design covering all eight Cloud Adoption Framework design areas, a platform landing zone deployed as code through your own pipelines, and policy guardrails running in audit mode with a dated plan to enforce them. By day 30 your team should own the repository, the pipelines and the runbooks, not just a diagram.

The timeline depends on the environment. A single-region platform landing zone for a greenfield tenant can often be done in a month, because Microsoft’s accelerator removes most of the custom build work. A brownfield estate with dozens of subscriptions, several regions, a monthly change board and workloads that cannot go offline takes longer, which is why we commit to a timeline in the proposal only after we have seen the environment. What follows is the pattern we plan around, not a promise.

The month at a glance

This is the shape of a typical single-region engagement. Treat the weeks as phases rather than fixed dates.

Week	Focus	Output by end of phase	Who we need from your side
1	Discovery and irreversible decisions	Current-state review; written decisions on tenant, management groups, regions, IP plan and tooling	Cloud owner, security lead, network lead, a finance contact
2	Design areas and decision log	Design across all eight design areas, decision log, policy set, network design	The same group, for two or three working sessions
3	Deployment with the accelerator	Platform landing zone deployed from your repository through CI/CD; policies assigned in audit mode	A platform engineer paired with ours
4	Policy review and handover	Compliance baseline, enforcement plan, runbooks, recorded walkthrough, first application landing zone	Platform team, operations, security

Multi-region networking, brownfield subscriptions that need to move, monthly change advisory boards and on-premises connectivity that depends on a third party all stretch this plan. ExpressRoute circuits, for example, run on your connectivity provider’s schedule. They belong in the timeline from the start.

Week 1: Discovery and the decisions that are hard to reverse

A landing zone is the foundation every future workload inherits. As we covered in our overview of Azure landing zones as a foundation for migration, its value is that new workloads start with security and cost controls already in place. That is also why the first week matters most. Tenant structure, management group hierarchy, IP address plan, network topology and tooling can all change later, but each change after workloads arrive means migration windows, re-peering, DNS rework and another round of approvals. In our engagements, organizations that compress these decisions to reach deployment sooner spend far more time in year two undoing them.

Discovery is short and specific: existing subscriptions and who holds Owner on them, on-premises IP ranges, identity configuration, compliance obligations and the infrastructure as code skills your team already has. For BC public sector and regulated organizations, residency requirements get written down here too; our post on Canadian data residency in Azure under FIPPA and PIPA covers that side. We also ask early for an account with the permissions the accelerator’s prerequisites require, and for your on-premises IP ranges, since both hold up later weeks if they arrive late.

Discovery exists to settle five decisions before anything is deployed:

• Tenant and billing. Which Microsoft Entra tenant hosts the platform and which agreement pays for it.
• Management group hierarchy. The reference architecture separates platform subscriptions (identity, management, connectivity) from application landing zones, with sandbox and decommissioned groups alongside. We adapt it to how you run the business.
• Regions. For most Canadian clients, Canada Central and Canada East, enforced by policy.
• IP address plan. Ranges that do not overlap with on-premises networks and leave room for three years of growth.
• Tooling. Bicep or Terraform, and GitHub or Azure DevOps. Microsoft’s accelerator asks for exactly these choices in its planning phase, and it supports both languages, so choose the one your team will maintain.

Each is cheap to change on a whiteboard in week one and costly once workloads depend on it.

Week 2: Design areas and the decision log

Microsoft’s Cloud Adoption Framework defines eight landing zone design areas: Azure billing and tenant, identity and access management, resource organization, network topology and connectivity, security, management, governance, and platform automation and DevOps. Microsoft groups the last four as compliance design areas, the ones you keep refining as new workloads and regulations arrive.

We work through each area with the people who own it, and the output is a design document plus a decision log. Each log entry records the decision, the options considered, the reason, who approved it, the date and what would trigger a revisit. It is what lets your team defend the design to an auditor, onboard a new engineer, or change a decision two years later without guessing why it was made.

Hub-and-spoke or Virtual WAN

Network topology is the design decision that is hardest to change later, so it gets settled in weeks 1 and 2 and deployed in week 3.

Microsoft’s guidance on defining an Azure network topology recommends Virtual WAN when you need global connectivity across several Azure regions and on-premises locations, when you are integrating a large branch network through SD-WAN or need native IPsec termination for more than 30 branch sites, or when you need transitive routing between VPN and ExpressRoute. Otherwise, a traditional hub-and-spoke topology gives you more control over the hub.

Our comparison of hub-and-spoke versus Virtual WAN for enterprise landing zones covers cost, routing and firewall design. The practical point for the first month is that DNS for private endpoints is designed with the topology, not after the first workload fails to resolve one.

Week 3: Deploying with the accelerator

Microsoft recommends deploying the platform landing zone with the Azure landing zones infrastructure as code accelerator, which uses Bicep or Terraform built on Azure Verified Modules and supports GitHub or Azure DevOps. It runs in four phases: planning, prerequisites, a bootstrap that prepares your Azure environment and repository, and a run phase where the customized code deploys through CI/CD.

We use it rather than hand-written templates because Azure Verified Modules are maintained by Microsoft. Your platform code stays aligned with the reference architecture and you can adopt Microsoft’s updates without rewriting it. Custom code written by a partner becomes custom code your team maintains alone.

Your platform engineer pairs with ours this week and runs the pipeline, because they will maintain it next. The policy set from week 2 is assigned at the management group level in audit mode, so it starts measuring without blocking anything.

If you already have Azure subscriptions and workloads, this is where the brownfield path diverges. We deploy the new management group structure alongside what exists and let audit mode measure the gap. Subscriptions then move, and findings get fixed, in order of risk, without taking running workloads offline. That work usually continues past day 30.

Week 4: Policy enforcement plan and handover

The landing zone assigns a large set of Azure Policy definitions at the management group level. Enforcing all of them on day one breaks running workloads.

Azure Policy handles this directly. An assignment’s enforcement mode can be set to DoNotEnforce, which evaluates and reports compliance without applying the effect, then switched to Default to enforce. Microsoft’s guidance on adopting policy-driven guardrails describes the same phased approach, starting with a sandbox or non-production scope.

In week 4 we review the compliance results with your team and agree an enforcement plan by scope and by policy. Low-risk guardrails, such as allowed regions for new resources, usually move to enforcement quickly. Policies that would block existing patterns get a date and an owner.

What your team should hold by day 30

A landing zone is a product your team will run, not a project we close. By the end of the month you should hold:

• The platform code in your repository, with pipelines that validate and deploy changes through pull requests
• The design document and decision log
• An enforcement plan for every policy still in audit mode
• Runbooks for recurring tasks: adding a subscription, requesting a policy exemption, updating module versions and responding to non-compliance alerts
• A recorded walkthrough for engineers who join later

The code, pipelines, decision log and runbooks live in your repository and tenant, so operating the platform does not depend on us. Our exit test is simple. Your engineer creates the first application landing zone through a pull request, with networking, policy, access and monitoring applied automatically, while we watch rather than drive. If you are still evaluating partners, our guide to choosing a Microsoft Azure partner in Vancouver covers the handover questions to ask before you sign.

After day 30

The month ends with a platform, not a finished governance program. The enforcement dates agreed in week 4 are the part most likely to slip. One of the most common findings in our landing zone reviews is policy left in audit mode indefinitely, and audit mode is a measuring tool, not a control. Whoever owns each date should treat it like any other production change.

From here the work is landing workloads and keeping the design current: new application landing zones through pull requests, module updates as Microsoft releases them, and decision log entries revisited when their triggers arrive. Our Azure landing zone consulting covers design, accelerator deployment, policy rollout and handover for new builds and for existing environments that need to come under governance. If you want to know what your own first 30 days would look like, book a consultation and we will walk through your current Azure setup.