Azure Landing Zone Transition Patterns — Migrating Existing Environments to Enterprise-Scale at Malaysia West

Most Malaysian enterprises did not start Azure with a landing zone. They started with a subscription, got workloads running, and ended up with sprawl — ad-hoc resource groups, inconsistent policies, scattered RBAC, and no management group hierarchy. This is not a failure. It is the normal evolution of most Azure tenants.

The good news is that Microsoft's Cloud Adoption Framework now has a well-defined, incrementally safe path to align brownfield environments with the Azure Landing Zone reference architecture. You do not have to tear everything down. You build the target in parallel and migrate progressively.

What a Brownfield Environment Looks Like

A brownfield Azure environment is any existing deployment that was not built to ALZ from the start. Common characteristics:

• One or a few subscriptions doing everything (platform and workloads mixed together)
• No management group hierarchy, or a flat/shallow one
• Policies applied ad-hoc at the subscription or resource group level
• RBAC assignments scattered at multiple scopes
• No centralized hub network or inconsistent connectivity design
• No separation of platform functions (identity, connectivity, management) from application workloads

If this describes your Azure tenant, you are in the majority. Microsoft's brownfield transition guidance — matured significantly in 2026 — is designed specifically for this reality.

The Target: Azure Landing Zone Reference Architecture

Before transitioning, understand what you are moving toward. The ALZ reference architecture defines eight design areas:

Note: The legend letters come from the official Microsoft Learn design-areas diagram (learn.microsoft.com). Several letters appear under more than one design area (Management spans D, G, and H; Governance spans C and D), which is why those rows list multiple letters.

The canonical management group structure:

Tenant Root Group
  └── [Your Org]
        ├── Platform
        │     ├── Identity
        │     ├── Connectivity
        │     └── Management
        ├── Landing Zones
        │     ├── Corp       (VNet-connected workloads)
        │     └── Online     (internet-facing workloads)
        ├── Sandbox
        └── Decommissioned

Workload subscriptions live under Corp or Online depending on whether they require private network connectivity.

The Golden Rule: Build in Parallel, Migrate Incrementally

The most important principle when transitioning a brownfield environment:

Never modify production in place. Deploy the new structure in parallel and migrate workloads progressively.

This guarantees:

• Active workloads are not disrupted during the transition
• Teams can assess policy compliance before enforcement takes effect
• Rollback is possible at any point — the old structure still works
• Migration can be paced by team capacity and risk tolerance

Phase 1: Assess Your Current State

Before moving anything, document what you have.

Inventory Resources

Use Azure Resource Graph:

Resources
| summarize count_=count() by type, subscriptionId
| order by count_ desc

(The count_=count() alias is required so order by count_ desc resolves; bare count() cannot be used directly in order by.)

Key questions to answer:

• How many subscriptions exist, and what is in each?
• Are platform resources (gateways, firewalls, DNS, monitoring) mixed with workload resources?
• What management groups exist today?
• What policies are assigned, at what scopes, and with what effects?
• What RBAC role assignments exist at which scopes?

Identify What Cannot Move

Some resource types do not support Azure Resource Manager move operations. Cross-reference your inventory against the supported resources list before planning any migrations.

Common resources that require care:

• Virtual Networks — peering must be removed first, then re-established after
• VPN Gateways and ExpressRoute Gateways — significant reconfiguration required
• Recovery Services Vaults — active backup or replication configurations cannot be moved
• Key Vault — access policies and firewall rules need review post-move
• Managed Identities — role assignments tied to ResourceId update on move

Audit Your Policy Landscape

PolicyResources
| where type == "microsoft.authorization/policyassignments"
| project name, properties.scope, properties.policyDefinitionId, properties.enforcementMode

This is critical input for the transition. You need to know what guardrails already exist before adding new ones.

Phase 2: Deploy the Target Structure (Parallel, Not Replacing)

Deploy the ALZ Management Group Hierarchy

Deploy the ALZ management group structure into your existing tenant without moving any subscriptions yet. This creates the target hierarchy alongside your current structure with zero impact to running workloads.

Options to deploy:

• Azure Landing Zones Bicep accelerator (current canonical): github.com/Azure/alz-bicep-accelerator — based on Azure Verified Modules for Platform Landing Zone
• Azure Landing Zones Terraform accelerator (current canonical): github.com/Azure/alz-terraform-accelerator — based on the Azure/caf-enterprise-scale/azurerm Terraform module (legacy module path: github.com/Azure/terraform-azurerm-caf-enterprise-scale)
• Azure Portal (accelerator UI): aka.ms/alz/acc — guides you through the Bicep or Terraform deployment

Note (Feb 2026): The classic Azure/ALZ-Bicep repo was removed on 16 February 2026. New deployments should use the alz-bicep-accelerator repo above, which is built on Azure Verified Modules (AVM) and is the documented successor.

The deployment creates:

• The management group hierarchy
• ALZ built-in policy assignments and initiatives
• Role definitions
• Diagnostic settings baseline

Configure Policies in Audit-Only Mode

This is the Microsoft-recommended brownfield approach. Set all policy assignments to DoNotEnforce mode:

{
  "properties": {
    "policyDefinitionId": "/providers/Microsoft.Authorization/policySetDefinitions/...",
    "enforcementMode": "DoNotEnforce"
  }
}

This creates a "shadow compliance" view:

• Resources that violate policies appear as non-compliant in the portal
• No deployments are blocked — Deny effects become no-ops
• DeployIfNotExists and Modify effects do not auto-remediate
• Application teams evaluate compliance findings without risk of disruption

Deploy Platform Subscriptions

Create new, clean subscriptions for platform functions:

Keep these separate from workload subscriptions from day one.

Phase 3: Migrate Workloads

Move Subscriptions into the New Hierarchy

Moving a subscription to a different management group does not affect existing resources within the subscription. ResourceId values do not change. The move primarily reorganizes governance boundaries.

Requirements:

• Owner, Contributor, or Management Group Contributor role on the source subscription
• Write permission on the target management group
• Assessment of inherited policies from the new parent management group

Move Resources Across Subscriptions

When moving resources between resource groups or subscriptions:

• Source and target resource groups are locked during the move
• ResourceIds are updated, which breaks existing monitoring, alerts, and automation
• Some resource types do not support move
• VNet peering must be disabled before moving virtual networks

Recommendation: Minimize resource moves. Move subscriptions into the management group hierarchy first. Only move individual resources when workload separation requires it.

Policy Compliance Assessment

After subscriptions are in the new hierarchy, review the non-compliance findings:

• Resources marked non-compliant under ALZ standards
• Group findings by policy and workload owner
• Create remediation plans with application teams
• Prioritize by security impact

Phase 4: Enable Enforcement

Remediate Non-Compliant Resources

Work through the remediation backlog systematically:

1. Critical security findings — public IPs on databases, missing encryption, unrestricted network access
2. Identity and access — excessive permissions, missing managed identities
3. Governance — missing tags, incorrect naming, resource organization
4. Networking — inconsistent DNS, missing NSGs, peer connectivity gaps

Transition from Audit to Enforce

Move subscriptions from the audit management group to the enforced management group as they become compliant:

# Check compliance status
az policy state list --management-group "YourOrg-LandingZones-Audit" --query "[?complianceState=='NonCompliant']" -o table

# Move when compliant
az account management-group subscription add \
  --name "YourOrg-LandingZones" \
  --subscription "subscription-id"

Decommission Old Management Groups

Once all subscriptions are moved and enforced, decommission the temporary audit management groups and any legacy structure.

Phase 5: Rebuild Platform

Hub Network Migration

The hub network migration is typically the most complex phase. The parallel approach:

1. Deploy new hub VNet in the Connectivity subscription
2. Configure VPN/ExpressRoute gateways
3. Establish new peering to spoke VNets
4. Migrate DNS resolution
5. Migrate firewall rules and network security groups
6. Cut over traffic
7. Decommission old hub network

Malaysia West specific considerations: The Malaysia West region (GA May 2025) makes this urgent as enterprises plan for dual-region architectures with the upcoming Johor Bahru region. Design your hub for West-to-JB connectivity from the start.

DNS Migration

Configure Azure DNS Private Zones for internal resolution:

• Split-horizon DNS for hybrid name resolution
• Private DNS zones linked to spoke VNets
• DNS forwarding between Azure and on-premises

Monitoring Migration

• Deploy Log Analytics workspace in the Management subscription
• Configure diagnostic settings for all platform resources
• Migrate existing alerts and dashboards
• Enable Defender for Cloud across all subscriptions

Malaysia West Specific Considerations

PDPA Compliance

Malaysia's Personal Data Protection Act applies to how data is organized, stored, and accessed in Azure. The ALZ governance layer provides the structure to implement PDPA controls:

• Data classification: Use Azure Policy to enforce sensitivity labels on storage and databases
• Access control: RBAC at management group scope ensures consistent access policies
• Audit logging: Centralized monitoring in the Management subscription provides audit trails
• Data residency: Malaysia West region keeps data within Malaysian jurisdiction

Hub Connectivity Design

For enterprises with on-premises data centers in Malaysia:

• ExpressRoute through local providers (Time, TM, Maxis) for production workloads
• VPN Gateway for backup connectivity and branch offices
• Consider Virtual WAN if you have multiple branch offices or need SD-WAN integration

Dual-Region Planning

With the Johor Bahru region expected:

• Design hub connectivity for West-to-JB peering
• Use Azure Policy to enforce region assignments for data sovereignty
• Plan for cross-region disaster recovery with Azure Site Recovery
• Consider availability zones in Malaysia West for intra-region resilience

Common Failure Patterns

Assessing Policy Compliance Too Late

Teams often enable enforcement before understanding the compliance gap. Always start in audit mode and build the remediation backlog before flipping to enforce.

Moving Recovery Services Vaults

Vaults with active backup or replication workloads cannot be moved in most cases. Create a new vault in the target subscription, reconfigure backups, and let the old vault's data age out per its retention policy.

Forgetting ResourceId Changes

Every resource move updates ResourceIds. Alerts, dashboards, runbooks, and ARM-based automation referencing old ResourceIds will stop working. Audit automation dependencies before any move.

Not Assessing RBAC Before Moving Subscriptions

Management group moves do not change direct RBAC on subscriptions, but they add inherited permissions from the new parent. Audit who would gain access before moving.

Over-Engineering the Initial Deployment

Deploy only the management group hierarchy and policies in Phase 2. Do not try to deploy hub networking, identity, and monitoring simultaneously. Phase them based on risk and team capacity.

Summary: The Transition Sequence

Phase 1: Assess current state
  └── Inventory resources, policies, RBAC
  └── Identify what can and cannot move

Phase 2: Build target in parallel
  └── Deploy ALZ management group hierarchy
  └── Assign policies in DoNotEnforce (audit) mode
  └── Create new Platform subscriptions

Phase 3: Migrate workloads
  └── Assess audit compliance findings with app teams
  └── Move subscriptions into new hierarchy
  └── Move resources across subscriptions where needed

Phase 4: Enable enforcement
  └── Remediate non-compliant resources
  └── Move subscriptions from audit to enforced
  └── Decommission old management groups

Phase 5: Rebuild platform
  └── Migrate hub network (parallel approach)
  └── Migrate DNS and monitoring
  └── Decommission old platform resources

The brownfield transition is not a one-time project. It is a continuous improvement process that moves your Azure environment from ad-hoc to governed without the risk of a big-bang migration. Start with assessment, build the target alongside your current state, and migrate when the compliance picture is clear. The enterprises that get this right do not just save on cost — they gain the governance foundation that makes every subsequent Azure investment more secure and more manageable.

Key Takeaways

1. Build in parallel, migrate incrementally. Never modify production in place. Deploy the ALZ management group hierarchy, audit-mode policies, and platform subscriptions alongside your existing structure, then move workloads one at a time as the compliance picture clears. This guarantees rollback is always possible and active workloads are never disrupted.
2. Start every policy in `DoNotEnforce`. Brownfield environments rarely pass ALZ baselines on day one. Use audit mode to build a remediation backlog with application teams, prioritise by security impact, and only flip to enforcement after non-compliance is driven to zero on the subscription or management group you are moving.
3. Minimize resource moves; move subscriptions instead. Moving a subscription to a new management group leaves ResourceIds untouched and preserves monitoring, alerts, and runbooks. Cross-subscription resource moves break ResourceIds, so reserve them for cases where workload separation truly requires it.
4. Plan for things that cannot move. Recovery Services Vaults with active backup, ExpressRoute gateways, and certain identity resources do not support ARM move. Sequence them out before the migration window: stand up a new vault, reconfigure backups, and let the old data age out per its retention policy.
5. Treat the target as Malaysia-aware from day one. If you are running in Malaysia West, design the hub for the upcoming Johor Bahru peering, keep regulated workloads inside Malaysian jurisdiction for PDPA, and use Azure Policy to enforce region assignment so the regional expansion is a configuration change rather than a redesign.