Edit

Share via

Scenario: Transition an environment by duplicating a landing zone management group

  • Article

This article describes an example approach that transitions an environment to the Azure landing zone conceptual architecture by duplicating the landing zone management group with policies in audit only mode. With this approach, you can quickly access the new desired target architecture and then assess the application or workload subscriptions for compliance. This approach eliminates the risk of affecting the application teams because the policies are in audit only mode.

Transition to the Azure landing zone conceptual architecture

Prior to implementing this approach, review Azure landing zone conceptual architecture, Azure landing zone design principles, and Azure landing zone design areas.

Use this approach to transition to the Azure landing zone conceptual architecture:

  1. Deploy the Azure landing zone accelerator into the same Microsoft Entra ID tenant in parallel with the current environment. This method provides a smooth and phased transition to the new landing zone architecture with minimal disruption to active workloads.

    This deployment creates a new management group structure. This structure aligns with Azure landing zone design principles and recommendations. It also ensures that these changes don't affect the existing environment.

    For information about minimizing disruption to applications and services during the migration, see Adopt policy-driven guardrails.

  2. To duplicate the landing zone management group and its children (corp and online in the following diagram) including all policy assignments, configure them to audit only mode. On the policy assignments, set the enforcementMode property to DoNotEnforce or Disabled.

    This approach provides quick access to the new desired target architecture. Then the applications teams can assess the policies without the risk of affecting active applications.

    Diagram that shows duplicate brownfield landing zones with audit only policies.

    Note

    This approach has no additional cost because it only duplicates the management group hierarchy and the assigned policies, not the workloads.

  3. (Optional) Work with application or service teams to migrate the workloads that are deployed in the original subscriptions into new Azure subscriptions. For more information, see Transition existing Azure environments to the Azure landing zone conceptual architecture. You can place workloads into the newly duplicated management group hierarchy under the correct management group, such as corporate brownfield or online brownfield in this example.

    For information about the effect on resources when migrating, see Policies.

    Eventually, you can cancel the existing Azure subscription, and place it in the decommissioned management group.

    Note

    You don't necessarily have to migrate the existing applications or services into new landing zones, or Azure subscriptions.

  4. After the application teams work with the platform teams to get their policy compliance into the required state, their subscriptions are moved to the proper management group, such as corporate or online in the following diagram. They're covered by the assigned policies and your team can efficiently and compliantly operate their workload.

    For more information, see Readying your landing zone for migration guidance.

The following diagram shows the state of this scenario during the migration.

Diagram that shows a single subscription environment in the transition state.

Summary

You used this approach to safely migrate your workloads in Azure by deploying the Azure landing zone conceptual architecture in parallel with your existing environment with minimal disruption.