How to Design an Enterprise Azure Landing Zone

An Azure landing zone is not a prebuilt network, a collection of policy definitions, or a single deployment template. It is the operating foundation that lets an organization place workloads in Azure repeatedly while keeping identity, governance, connectivity, security, operations, and cost under control.

That distinction matters. A team can deploy a technically impressive hub network and still have no reliable way to issue subscriptions, assign ownership, grant temporary privileged access, handle exceptions, or recover the platform. Conversely, a carefully designed landing zone can start small and evolve because its decisions, boundaries, and automation are explicit.

This guide develops a reference architecture for a hypothetical global manufacturer with on-premises Active Directory Domain Services (AD DS), several regions, regulated data, and many application teams. It is intentionally synthetic: no customer, employer, tenant, subscription, address space, or production configuration is represented. Use it as a decision framework, then validate every choice against your own requirements and the current Microsoft Cloud Adoption Framework Azure landing zone guidance.

1. Begin with the right mental model

Microsoft describes an Azure landing zone as a standardized, recommended approach for preparing an Azure environment at scale. The conceptual architecture contains two related types of landing zone:

• The platform landing zone hosts shared capabilities such as identity connectivity, network connectivity, management, and security operations.
• Application landing zones host workloads. They are commonly subscriptions separated by application environment, ownership, risk, or lifecycle.

The platform is therefore not the destination for every shared-looking resource. It is the governed service that makes workload subscriptions consumable. Application teams should receive a subscription with a known identity boundary, network connection, policy baseline, logging path, budget, and support route—not an empty subscription plus a diagram.

The control hierarchy is also different from the identity hierarchy:

Microsoft Entra tenant
  └─ authenticates people, applications, and managed identities

Azure Resource Manager tenant scope
  └─ management group
       └─ subscription
            └─ resource group
                 └─ resource

These scopes interact, but they are not interchangeable. Microsoft Entra roles administer directory capabilities. Azure role-based access control (RBAC) authorizes operations on Azure resources. A subscription is a billing, quota, deployment, and management boundary, but should not be treated as the only security control. Network segmentation, identity permissions, data-plane authorization, policy, and workload controls still matter.

Three distinctions prevent many early design errors:

Concept	Purpose	It is not
AD DS	Traditional domain services: Kerberos, NTLM, LDAP, Group Policy, and domain join	The Azure resource control plane
Microsoft Entra ID	Cloud identity and access for users, applications, devices, and services	A direct replacement for every AD DS capability
Azure Resource Manager	The consistent Azure control plane used to deploy and govern resources	An identity directory or workload data plane

Microsoft Entra Domain Services is a managed domain-service option for workloads that still require compatible domain join, LDAP, Kerberos, or NTLM. It is not the default answer for extending an existing enterprise forest, and it does not make all legacy identity decisions disappear.

2. Decide whether the organization needs a landing zone program

Every Azure environment needs basic governance, but not every environment needs the same platform organization. A small, isolated experiment might reasonably use one subscription, a few audit policies, a budget, and a documented owner. A landing zone program becomes valuable when multiple teams need repeatable environments or when the organization has material requirements for any of the following:

• Hybrid connectivity and name resolution
• Central identity and privileged-access controls
• Multiple workload environments or business units
• Regulatory separation or data residency
• Central logging and incident response
• Reusable policy, security, and cost guardrails
• Subscription lifecycle automation
• Acquisitions, divestitures, or a complex existing Azure estate

The signal is not simply resource count. The stronger signal is the number of ownership boundaries, compliance profiles, connectivity paths, and lifecycle events the platform must handle.

Treat the landing zone as a product with customers, an owner, a roadmap, and a feedback loop. A platform product can publish supported patterns, measure adoption, and improve the paved road as requirements change.

3. Run an architecture design session before selecting modules

A productive architecture design session converts business and technical constraints into decisions. It should happen before a team chooses a portal accelerator, Bicep module, Terraform module, or network appliance.

At minimum, bring representatives from cloud platform, security, identity, network, operations, finance, compliance, and application delivery. Capture evidence for these questions:

1. Business and geography: Where are users, factories, offices, and customers? Which workloads are critical? What are the recovery objectives?
2. Identity: Which forests and tenants exist? How are users synchronized? Which applications depend on LDAP, Kerberos, or legacy service accounts?
3. Network: What address space is allocated? Which sites connect to Azure? Where are DNS, ingress, egress, and inspection controlled?
4. Governance: Which regulations, data classifications, allowed regions, tagging rules, and ownership standards apply?
5. Operations: Who monitors the platform around the clock? Which ticketing, incident, backup, and change processes exist?
6. Delivery: Which source-control and CI/CD systems are approved? Who can review and release platform changes?
7. Commercial constraints: Which billing agreements, quotas, licenses, and cost-allocation requirements apply?

The session should produce more than a slide deck. Its minimum outputs are a target architecture, scope hierarchy, identity and connectivity decisions, policy and logging baselines, a responsibility model, an exception process, an automation approach, a migration sequence, and a decision log.

Classify the environment honestly. A greenfield organization can create the hierarchy and automation before workloads arrive. A brownfield organization must discover existing subscriptions, role assignments, policies, routes, diagnostic settings, identity dependencies, and production owners before moving anything. In brownfield work, imposing the target hierarchy without dependency analysis can interrupt policy inheritance, connectivity, or operational ownership.

4. Cover all eight design areas

The Cloud Adoption Framework design areas are useful because they prevent a network-only or policy-only architecture:

Design area	Decisions that must be explicit
Billing and tenant	Agreement, tenant ownership, subscription creation, quota, and chargeback
Identity and access	Authentication, synchronization, RBAC, PIM, emergency access, workload identity
Resource organization	Management groups, subscription purpose, naming, tags, lifecycle
Network topology and connectivity	Hub model, routing, DNS, ingress, egress, private access, hybrid links
Security	Posture management, workload protection, data protection, incident ownership
Management	Inventory, monitoring, logging, backup, patching, recovery, support
Governance	Policy hierarchy, compliance evidence, exemptions, remediation
Platform automation and DevOps	Repositories, modules, pipelines, state, approvals, testing, drift

The design should also follow the five principles in Microsoft’s Azure landing zone design guidance: democratize subscriptions within guardrails, drive governance with policy, rely on the common Azure Resource Manager control plane, organize the service model around applications, and align with Azure-native capabilities and roadmaps unless requirements justify something else.

Those principles are defaults, not excuses to ignore context. Document the requirement, cost, operational consequence, and exit condition behind each deviation.

5. Define a target operating model

The reference enterprise uses centralized guardrails with decentralized workload delivery:

Corporate Microsoft Entra tenant
│
├─ Platform management groups
│  ├─ Identity subscription
│  ├─ Connectivity subscription
│  └─ Management/Security subscription
│
└─ Landing Zones management groups
   ├─ Corp       -> workloads requiring corporate or hybrid connectivity
   ├─ Online     -> internet-facing or cloud-native workloads
   ├─ Regulated  -> workloads with an additional approved control profile
   ├─ Sandbox    -> constrained experimentation
   └─ Decommissioned -> quarantined subscriptions awaiting closure

The platform team owns the hierarchy, shared services, subscription-vending product, and platform code. Security owns security standards and detection requirements but collaborates on implementations. Identity and network teams own their domains. Workload teams own application resources, data, remediation, and availability inside their subscriptions. Finance defines allocation and reporting. Compliance verifies that controls meet obligations.

6. Use one corporate tenant by default

For most enterprises, a single corporate Microsoft Entra tenant provides the best starting point. It supports consistent identity policy, collaboration, administrative governance, and visibility across many Azure subscriptions. Microsoft’s multi-tenant guidance recommends considering additional tenants only when requirements cannot be satisfied in the existing tenant.

Valid exceptions can include legal isolation, sovereign or national-cloud requirements, a divestiture boundary, or an acquired company that cannot yet be integrated. “Business units want independence” is not by itself a sufficient reason. Every tenant adds privileged roles, emergency accounts, application registrations, policy surfaces, licenses, logs, cross-tenant access, and incident-response paths.

For each proposed tenant, record the unmet requirement, identity and collaboration experience, cross-tenant administration, incident response, cost, expected lifetime, and consolidation or divestiture plan.

Tenant consolidation does not mean granting broad access. Use administrative units, groups, PIM-eligible roles, access reviews, Conditional Access, and Azure RBAC scopes to delegate responsibility. Keep directory administration separate from Azure resource administration and require independent approval for the most powerful roles.

7. Keep the management-group hierarchy shallow and policy-oriented

A management group is a governance scope above subscriptions. It should exist because a set of subscriptions needs common policy or access—not because a box exists on the organization chart. Microsoft’s management-group guidance recommends a shallow hierarchy, ideally three to four levels in most cases, even though Azure supports greater technical depth.

A reasonable hierarchy for the reference enterprise is:

Tenant root
├─ Platform
│  ├─ Identity
│  ├─ Connectivity
│  └─ Management
├─ Landing Zones
│  ├─ Corp
│  ├─ Online
│  └─ Regulated
├─ Sandbox
└─ Decommissioned

Assign broad, universal controls near the top: allowed identity model, activity-log export, required security contacts, or globally prohibited configurations. Assign archetype-specific controls lower down: hybrid DNS requirements for Corp, public-ingress constraints for Online, or an additional encryption and logging profile for Regulated.

The current reference hierarchy also includes a Local archetype for Azure Local workloads. It is omitted from this synthetic example because the scenario does not use Azure Local—not because that archetype is generally unnecessary.

Avoid creating a management group for every department, application, or cost center. Tags and billing data are better tools for cost reporting, while subscriptions are better workload lifecycle boundaries. Hierarchy changes are possible, but moving subscriptions can alter inherited policies and RBAC, so treat moves as reviewed changes with impact analysis.

Do not place normal workloads under the tenant root or the Platform branch. Also define automatic handling for newly created subscriptions so that they cannot remain indefinitely in an ungoverned default location.

8. Make subscriptions the unit of workload scale

An application landing zone commonly maps a workload environment to a subscription. Separate production from non-production when different access, change, quota, cost, or incident requirements justify it. Highly regulated data, high-risk internet exposure, and major regional differences can justify additional subscriptions. Do not split merely to make a diagram symmetrical.

AI does not require a separate enterprise landing-zone hierarchy by default. Treat an AI solution as an application workload and place its environments in application landing zones. Add a dedicated subscription product or policy archetype only when its data, model, accelerator quota, network, or operating requirements genuinely differ.

A practical subscription record includes:

Field	Example meaning
Workload and environment	Identifies service ownership and lifecycle
Business owner and technical owner	Establishes accountability and escalation
Management-group archetype	Selects the inherited guardrail set
Data classification	Drives additional controls and evidence
Region and connectivity class	Selects address, DNS, route, and hub attachment
Cost center and budget	Enables allocation and alert routing
Recovery tier	Connects platform dependencies to workload RTO/RPO
Expiration or review date	Prevents abandoned sandboxes and temporary environments

Use a stable internal subscription identifier or alias rather than depending on a display name as the system of record. Names can be human-readable, but they should not encode every mutable attribute. Resource tags should support operations and finance; they do not enforce network or access isolation and can be modified unless policy and permissions constrain them.

Subscription vending is a service, not a form

Subscription vending is the programmatic issuance and configuration of governed subscriptions. A request should be validated, approved according to risk, created under the correct billing scope, placed in the correct management group, and configured before handoff.

A mature vending flow looks like this:

Workload request
  -> schema and ownership validation
  -> risk-dependent approval
  -> subscription creation and placement
  -> baseline RBAC, budget, tags, logging, network, and policy
  -> automated validation
  -> handoff with documentation and support route

Vending should also support change and closure. Workloads need a route to request quota, networking, policy exemptions, ownership changes, or new environments. Decommissioning should revoke access, preserve required records, disconnect connectivity, clean resources, resolve billing, and eventually close the subscription.

9. Design hybrid identity as a dependency, not an afterthought

The reference enterprise retains AD DS because some applications still depend on Kerberos, LDAP, Group Policy, or domain join. The safe pattern is to extend the domain with newly built, supported domain controllers in Azure when resilience requirements justify it. Do not copy or lift a running domain-controller virtual machine as an ordinary server image.

Place Azure domain controllers in a dedicated identity subscription and subnet, restrict administration, integrate them into AD Sites and Services, and design DNS deliberately. Confirm time synchronization, backup and recovery procedures, replication paths, monitoring, and the operational owner. Domain controllers are not general-purpose management hosts.

Microsoft Entra synchronization should be selected against actual feature requirements. Microsoft Entra Cloud Sync uses lightweight agents and cloud-managed configuration and is Microsoft’s strategic direction for many hybrid scenarios. Microsoft Entra Connect Sync still supports requirements that Cloud Sync might not meet. Use the current feature comparison and decision guide rather than declaring one tool universally superior.

Password hash synchronization is often a resilient authentication option, but authentication design must consider regulatory requirements, federation dependencies, passwordless plans, and emergency operation. Test loss of on-premises connectivity and loss of an agent, not only the happy path.

10. Control privileged and workload access

Human administrators should use dedicated privileged identities where the organizational design requires them, phishing-resistant authentication where supported, and Privileged Identity Management (PIM) for time-bound activation where configured and licensed. Separate directory roles from Azure RBAC roles. A person who operates virtual machines rarely needs Global Administrator; an identity administrator rarely needs subscription Owner.

Use groups for role assignment, scope roles narrowly, and avoid permanent Owner assignments. Review inherited access at management-group scope because a single assignment there can reach many subscriptions. Protect the ability to create role assignments, policy exemptions, managed identities, credentials, and networking changes as privileged actions.

Maintain at least two monitored emergency-access accounts following Microsoft’s current guidance. They should be cloud-only, excluded only from controls that could cause total lockout, protected with strong methods, and tested through a documented procedure. An emergency account is not a convenience administrator.

For applications, prefer managed identities and workload identity federation over stored client secrets. Separate deployment identities by environment and trust boundary. A pipeline that can deploy to development should not automatically be able to modify production or the platform hierarchy. Credential rotation does not compensate for an identity whose permissions are excessive.

11. Select network topology from operating requirements

Hub-and-spoke and Azure Virtual WAN are both valid patterns. Choose based on connectivity scale, routing requirements, appliance integration, global operations, automation maturity, and cost—not on diagram preference.

Hub-and-spoke

A customer-managed hub virtual network provides explicit control over routing, firewalls, gateways, DNS, and shared services. It also places more responsibility on the team to automate peering, routes, high availability, and regional expansion.

Azure Virtual WAN

Virtual WAN provides a managed global transit architecture with integrated branch, VPN, ExpressRoute, and security capabilities. It can reduce custom routing work, but still requires careful design for route intent, inspection, DNS, resilience, and cost.

In either pattern, answer these questions before provisioning:

• Who owns global IP address management, and how are overlaps prevented?
• Which traffic must traverse inspection, and which exceptions are legitimate?
• Where do internet ingress, outbound egress, and TLS termination occur?
• How do private endpoints resolve from Azure, on-premises, and developer networks?
• How are routes and DNS records created and removed with a subscription?
• What continues to operate if a hub, circuit, DNS resolver, firewall, or region fails?

Allocate address space from an enterprise IPAM process. Reserve for growth and acquisitions. Overlapping networks complicate peering, hybrid routing, private endpoints, and disaster recovery; late renumbering is expensive.

Private access requires DNS engineering

A private endpoint assigns a private network interface for a platform service, but it does not by itself make name resolution correct. Design private DNS zones, links, forwarding, record lifecycle, split-horizon behavior, and on-premises resolution as one system. Test the service’s public name from every relevant resolver path and confirm that it resolves to the intended private address.

Likewise, ExpressRoute is private connectivity, not a complete encryption or security architecture. Evaluate confidentiality requirements, route filtering, inspection, DDoS protection, and service-specific controls separately.

12. Roll out Azure Policy as code and in stages

Azure Policy makes the platform’s intent testable at scale. Its job is to evaluate resource state and, depending on the selected effect, audit, modify, deploy supporting configuration, or deny a request. It is not a substitute for secure application code, network design, or RBAC.

DeployIfNotExists and Modify assignments need a managed identity and the required roles to change resources. Existing noncompliant resources also need an explicit remediation task; assigning a policy does not guarantee that historical drift is repaired. A Deny assignment blocks applicable new or updated requests but does not retroactively rewrite existing resources.

Build initiatives around outcomes instead of assembling hundreds of disconnected definitions. Examples include:

• Approved regions and resource types
• Required ownership and data-classification metadata
• Diagnostic export for supported resources
• Private-access and public-network restrictions by workload archetype
• Encryption and key-management requirements
• Defender for Cloud configuration required by the security baseline

Use a controlled rollout:

Definition and unit test
  -> audit in a representative scope
  -> assess false positives and existing noncompliance
  -> remediate where the effect supports it
  -> pilot deny on new deployments
  -> broaden enforcement with monitoring and rollback

Do not enable a broad deny assignment at the tenant root without impact analysis. Existing resources, deployment tooling, regional feature availability, and managed-service behavior can make an apparently simple policy disruptive.

An exemption must be a governed object, not a verbal agreement. Record the business owner, technical owner, justification, risk acceptance, compensating controls, affected scope, approval, expiration date, and review evidence. Expired exemptions should alert and return to review automatically.

13. Treat data protection and key management as architecture

Classify data before choosing controls. For each workload, identify confidentiality, integrity, retention, residency, recovery, and deletion requirements. Then decide encryption, key ownership, access, backup, and logging accordingly.

Azure Key Vault has distinct control-plane and data-plane permissions. Granting someone the ability to manage the vault resource should not automatically imply access to every secret or key. Prefer Azure RBAC where it fits the service and organizational model, use managed identities, restrict network access where required, enable appropriate recovery protections, and monitor sensitive operations.

Soft delete is enabled by default for new vaults and, once enabled, cannot be disabled. Purge protection is a separate decision. Verify both settings, their retention implications, and the recovery procedure instead of assuming that the service default satisfies the organization’s deletion and recovery controls.

Customer-managed keys add responsibility. They can satisfy a control requirement, but the organization must operate key permissions, rotation, availability, recovery, and dependent-service behavior. A key that is inaccessible during an incident can become an availability failure. Document who can disable or delete keys, how emergency recovery works, and how dependent workloads are tested.

Storage protection must include data-plane authorization and exfiltration paths, not only encryption at rest. Prefer identity-based access over shared keys when supported, restrict public exposure, use lifecycle and immutability features where requirements demand them, and test restoration. Backup success messages are not proof that an application can be recovered within its objective.

14. Connect posture management, logging, and detection

Microsoft Defender for Cloud can provide cloud security posture management and, when relevant plans are enabled, workload protections for supported resources. Treat recommendations and Secure Score as prioritization inputs. A higher score does not prove that the environment is secure, and a lower score does not establish that every recommendation has equal risk.

Prioritize findings using exploitability, exposure, asset value, attack paths, compensating controls, and remediation effort. Establish ownership: the platform team may remediate a missing platform diagnostic setting, while the workload team owns a vulnerable container image.

Build a telemetry architecture

Separate the data sources and routing mechanisms:

• Azure Activity Log records subscription-level control-plane events.
• Resource logs and metrics expose service-specific events when supported and enabled.
• Diagnostic settings route supported platform data to destinations such as Log Analytics, Storage, or Event Hubs.
• Data collection rules define supported collection pipelines for sources such as Azure Monitor Agent and custom logs.
• Microsoft Sentinel uses connected data, analytics, hunting, incidents, and automation for security operations.

For current implementations, use the Microsoft Defender portal as the primary Microsoft Sentinel experience. Microsoft states that Azure portal support for Sentinel ends on March 31, 2027, so keep operational runbooks focused on capabilities and APIs rather than brittle portal click paths. See the Microsoft Sentinel Defender portal transition guidance.

A useful flow is:

Identity, control-plane, network, and workload signals
  -> documented collection and transformation
  -> workspaces or streaming/archive destinations
  -> detections and correlation
  -> incident ownership and response
  -> retained evidence and lessons learned

Centralization does not require sending every byte to one workspace. Design workspace topology from residency, access, retention, query, incident, and cost requirements. Test detections with synthetic events across the entire path from ingestion to incident closure.

15. Design operations and recovery across platform dependencies

Landing-zone availability is more than redundant virtual machines. Workloads can depend on Entra authentication, DNS, hub routing, firewalls, private DNS zones, secrets, deployment pipelines, monitoring, and platform support. Map those dependencies to the workload’s recovery objectives.

The operations baseline should define:

• Inventory and configuration visibility
• Service health and resource health routing
• Platform and workload alert ownership
• Patching and vulnerability remediation
• Backup policy and restore testing
• Capacity, quota, certificate, secret, and key-expiry monitoring
• Runbooks for identity, network, policy, and logging failures
• Escalation and vendor-support procedures

Use availability zones and multiple regions only where the business objective justifies the complexity and cost. A secondary region is not a recovery solution until identity, data replication, networking, DNS, secrets, deployment artifacts, and operating procedures are aligned and tested.

Run failure exercises at safe scopes. Examples include an unavailable DNS forwarder, failed private-endpoint resolution, lost hybrid connectivity, an expired deployment credential, a deny policy blocking an urgent deployment, or an unavailable logging destination. Record time to detect, decide, recover, and communicate.

16. Make FinOps and accountability part of the platform

Cost management begins during subscription issuance. Require a cost center, owner, environment, budget, and expected lifetime. Route budget alerts to people who can act, and remember that a budget is generally an alerting mechanism—not a hard spending cap.

Provide teams with regular views of actual cost, forecast, anomalies, commitments, and idle resources. Platform costs such as hub firewalls, ExpressRoute, shared monitoring, Defender plans, and data retention need an explicit allocation model. Otherwise the shared platform appears “free” to consumers and unexpectedly expensive to its owner.

A concise responsibility model might be:

Capability	Accountable owner	Important collaborators
Tenant identity and privileged roles	Identity	Security, platform, audit
Management groups and subscription vending	Platform	Finance, security, workload teams
Hybrid and cloud network	Network	Platform, security, application owners
Policy and control standards	Security/GRC	Platform, identity, network
Security monitoring and incident response	Security operations	Platform and workload teams
Application reliability and data	Workload owner	Platform, security, business owner
Cost allocation and optimization	Finance/FinOps	Platform and workload owners

The exact RACI can vary, but every control needs an accountable owner and an operator.

17. Implement the landing zone through infrastructure as code

Portal-based deployment can help a team learn concepts or create an initial demonstration, but an enterprise platform needs repeatability, review, testing, and traceable change. Microsoft’s implementation options recommend the Azure Landing Zone IaC Accelerator and Azure Verified Modules for Bicep or Terraform as supported starting points.

Choose Bicep or Terraform based on operating skills, approved tooling, state-management requirements, and the surrounding portfolio. Either can produce a strong platform. Neither fixes an unclear architecture.

A practical repository model separates concerns:

platform-live/       # environment composition and approved parameters
platform-modules/    # reusable, versioned modules
policy-library/      # definitions, initiatives, tests, exemptions
subscription-vending/# request schema and lifecycle automation
validation/          # static checks, policy tests, deployment tests
runbooks/            # recovery and operational procedures

The exact repository count is less important than clear ownership and release boundaries. Pin module versions, review upstream changes, and promote releases through representative non-production scopes before production.

For Terraform, protect remote state with encryption, narrow data-plane access, versioning or recovery controls, locking, and separate state boundaries that limit blast radius. For Bicep, protect deployment identities and deployment histories, and design module registries and versioning deliberately. In both cases, avoid exposing secrets in parameters, plans, state, pipeline logs, or artifacts.

An enterprise pipeline should perform:

1. Formatting, linting, and schema validation
2. Static security and policy checks
3. Module and dependency provenance checks
4. Plan or what-if generation
5. Human review for privileged or production changes
6. Deployment with a narrowly scoped workload identity
7. Post-deployment tests and evidence capture
8. Drift detection and an owned remediation path

Do not allow routine portal changes to become an invisible second source of truth. Emergency changes need a break-glass process and must be reconciled into code afterward.

18. Build a cost-constrained proof of concept

A useful PoC proves the operating model without pretending to be production. State which controls are demonstrated rather than fully implemented.

Minimum PoC scope

• A shallow management-group hierarchy and separate platform/application scopes
• One subscription-vending request schema with automated validation
• A small audit-mode policy initiative and group-based RBAC
• Activity Log routing and selected diagnostic settings
• A representative network and private DNS path
• Budget alerts, ownership metadata, and a time-limited exception
• A CI/CD path with plan, approval, deployment, validation, and redacted evidence

Avoid enabling every paid security plan, retaining high-volume logs indefinitely, or deploying multi-region transit only for a screenshot. Estimate recurring costs before deployment, set alerts, impose a lab expiration date, and remove resources through the same automation used to create them.

The PoC succeeds when it answers design risks: Can a new subscription inherit the intended guardrails? Can an application owner deploy within them? Does private DNS work end to end? Can the team observe a denied change? Can an approved exception expire? Can the platform be recreated and safely removed?

19. Migrate through controlled waves

A brownfield landing-zone adoption should start with discovery and containment, not immediate reorganization.

Wave 0: Discover

Inventory tenants, subscriptions, management groups, role assignments, policies, connectivity, DNS, logs, security tooling, costs, owners, quotas, and critical dependencies. Mark unknown ownership as a risk, not as an empty spreadsheet cell.

Wave 1: Establish platform minimums

Create the target hierarchy, platform ownership, identity controls, policy library, log-routing baseline, network foundations, subscription-vending path, and exception process. Deploy initially with low-impact controls and validate operational readiness.

Wave 2: Pilot workloads

Choose representative but recoverable workloads. Include at least one hybrid workload, one cloud-native workload, and one workload with stricter data requirements if those patterns exist. Measure friction and update the paved road.

Wave 3: Migrate by archetype

Group migrations by common network, identity, regulatory, and operating patterns. Remediate dependencies before moving subscriptions or enforcing denies. Give each wave explicit rollback, support, and communications plans.

Wave 4: Enforce and optimize

Broaden deny controls after compliance evidence, remediate drift, reduce standing privilege, tune telemetry, automate lifecycle operations, and decommission old paths.

Every wave needs exit criteria. Useful criteria include named owners, tested access, validated DNS and routes, successful log ingestion, policy compliance or approved exceptions, cost allocation, backup restore evidence where applicable, deployment-path validation, and an accepted recovery plan.

20. Validate qualities, not only resources

A deployment that reports “succeeded” is not necessarily operable. Validate the architecture against quality attributes:

Quality	Example test
Security	A developer cannot assign privileged roles or bypass required ingress controls
Reliability	Loss of a DNS or network component follows the documented recovery path
Operability	An on-call engineer can identify the owner and relevant signals for an alert
Scalability	Multiple subscription requests can be processed consistently without manual drift
Maintainability	A module or policy version can be upgraded through staged scopes
Cost efficiency	Owners receive actionable budgets and abandoned resources are identified
Compliance	Required evidence can be reproduced without screenshots containing sensitive data

Automate validation where possible: query effective policy and roles, test routes and DNS, verify diagnostic destinations, inspect deployment identity permissions, and confirm alert delivery. Store evidence with a timestamp, scope, method, expected and actual results, reviewer, and redaction status.

21. Avoid common anti-patterns

Mirroring the organization chart in management groups. Organizations reorganize frequently; governance requirements should drive the hierarchy.

One giant production subscription. It couples quotas, access, billing, deployment, and incident blast radius across unrelated workloads.

One subscription per resource group by default. Excessive fragmentation creates operational overhead without a requirement-backed boundary.

A shared-services dumping ground. Platform subscriptions should contain deliberately owned platform capabilities, not every resource described as shared.

Root-level deny on day one. Broad enforcement before audit and remediation can break deployments and managed services.

Permanent Owner and Global Administrator access. Standing broad privilege increases the impact of credential compromise and mistakes.

Private endpoints without DNS ownership. The endpoint exists, but clients resolve the public address or fail unpredictably.

Central logging without use cases. Ingestion grows while detections, retention, access, and incident ownership remain undefined.

Treating Secure Score as certification. It is a posture-management input, not proof of security or compliance.

Manual portal as the production source of truth. The environment cannot be reviewed, reproduced, or recovered consistently.

Calling a budget a spending limit. Alerts do not inherently stop resources, and automatic shutdown can create reliability risk.

Copying an on-premises domain controller into Azure. Build supported new domain controllers and validate replication and recovery.

22. Record decisions that will outlive the project

Use architecture decision records (ADRs) for choices with long-term cost or constrained reversibility. Each record should contain context, considered options, decision, rationale, consequences, owner, review date, and linked evidence.

At minimum, record:

• Single-tenant default and approved multi-tenant exceptions
• Management-group hierarchy and archetype definitions
• Subscription boundary and vending lifecycle
• Hybrid identity synchronization and authentication model
• Hub-and-spoke or Virtual WAN selection
• DNS and private-endpoint architecture
• Ingress, egress, inspection, and hybrid-connectivity choices
• Policy rollout, exemption, and remediation process
• Workspace, retention, archive, and Sentinel design
• Key ownership and recovery model
• IaC tool, module strategy, pipeline, and state boundaries
• Platform/workload responsibility and cost-allocation model

Decision records keep the architecture explainable when staff, regulations, services, and business structures change. They also make it possible to revisit a choice based on its original assumptions instead of mythology.

23. Final perspective

The best enterprise landing zone is not the one with the most subscriptions, policies, security products, or architecture boxes. It is the one that turns organizational intent into a repeatable service: a workload team can request an environment, receive safe defaults, understand its responsibilities, deploy without unnecessary delay, and obtain help when something fails.

Start with tenant, ownership, hierarchy, subscription, and connectivity decisions. Make identity and DNS first-class dependencies. Roll policy out through evidence. Connect telemetry to detections and people. Put the platform in code, but keep architecture decisions outside the implementation tool. Then migrate in waves with explicit exit criteria.

Azure services and Cloud Adoption Framework guidance continue to evolve. Revalidate product capabilities, limits, licensing, and implementation modules before a production rollout. The durable asset is not a frozen template; it is the organization’s ability to make, automate, test, and revisit platform decisions.

Official references

• What is an Azure landing zone?
• Azure landing zone design areas
• Azure landing zone design principles
• Management groups and subscription organization
• Subscription vending guidance
• Azure landing zone implementation options
• Multi-tenant Azure landing zone considerations
• What is Microsoft Entra Cloud Sync?
• Choose between Cloud Sync and Connect Sync
• Azure Policy DeployIfNotExists effect
• Azure Key Vault soft-delete overview
• Microsoft Sentinel in the Defender portal