Brownfield Rollout

"Brownfield" means an environment that already exists, with subscriptions, resources and running workloads; its opposite, "greenfield", is a new one where nothing is built yet. If you have nothing yet, read the greenfield rollout post.

No documentation page is named "brownfield rollout". The page "Journey toward the target architecture" names three starting points, Start (new), Align (existing, needs changes) and Enhance (already in line), and uses the word for Align. It links to a transition page, three scenario pages, an approach page and a page on refactoring a landing zone. This post turns those, plus the moving, policy and Azure CLI pages, into a playbook. Where the order or reading is mine, I say so.

How to read this post. The top of each section is the short version. Commands, runbooks and tables sit in boxes you can open. If you only have five minutes, read the manager summary and the company case.

For managers: the summary

For the people who approve the work. Items marked "my suggestion" are mine. Words used here: a policy is a rule Azure checks resources against; audit-only means a policy only reports and blocks nothing; Decommissioned is the group where retired subscriptions wait; a tenant is your organization's one Microsoft Entra directory; a subscription is a billing and access container for Azure resources; a management group is a folder that holds subscriptions and passes policy and access down to them.

• What changes. A new group structure and policy set is built beside the current environment in the same tenant. Then existing subscriptions move in, one wave (a small batch) at a time. Moving workloads into new subscriptions is optional.
• What does not change. A subscription move does not change resource IDs or touch running resources. The subscription does inherit the group's access and policy, which apply to new changes. Existing resources that break a policy are only reported; new deployments are denied only by a policy with the Deny effect.
• Main risk. A new deployment can be denied by policy. Control: run the policies in audit-only mode first.
• Second risk. Moving individual resources changes their IDs and locks resource groups for up to four hours. Control: move subscriptions, not resources, where you can.
• Cost (my reading). The audit-only copies add no resources of their own. The new platform resources do.
• Approve (my suggestion): a named owner and a rollback owner per subscription, a change window per wave, and the right to stop a wave at the first policy denial.
• Done means: every subscription is in its planned group, every non-compliant resource has an owner, and retired subscriptions sit in Decommissioned.

Key terms

Earlier posts defined landing zone and guardrail, subscription and management group, Corp, Online, Sandboxes and Decommissioned, hub network and peering, and, in the governance post, policy effects, DeployIfNotExists (DINE), Modify and non-compliant.

Your starting point at a glance

Pick the line that matches you. The steps after it are the same for every line.

The three scenarios share the same steps: deploy in parallel in the same tenant, optionally migrate workloads into new subscriptions under Corp or Online, and create new subscriptions for new landing zones.

The brownfield path at a glance

Seven stages; the two stages "See the effect" and "Move in" repeat for each wave.

Figure 1. The brownfield path, from today's environment to governed workloads.

The end state is the architecture in the greenfield rollout, built beside your old environment. The old environment keeps running, and old subscriptions can retire into Decommissioned.

A company case: one tenant, many subscriptions

This is a made-up manufacturer with made-up numbers, but the situation is a typical one.

• One Microsoft Entra tenant and an Enterprise Agreement.
• 38 subscriptions, all directly under the tenant root group.
• Four departments, each with its own Enterprise Agreement account and an account owner who creates subscriptions when a team asks.
• Owner rights were given to individual people, one subscription at a time. Nobody can name the owner of 9 subscriptions.
• No policy at group level. Approval for a new subscription is an email to the account owner.

My reading: the problem is not technical. Billing and access are two separate systems, and nobody owns the whole picture.

Who controls what

An account owner creates subscriptions. That role is a billing role, set in the Enterprise Agreement. It can also manage role assignments on the subscriptions it owns. In my reading, it does not control policy or the management group tree; those come from Azure roles and management groups. The two systems meet at the subscription.

Figure 2. Billing and access meet at the subscription.

What matters here:

• An enterprise administrator or an account owner can create subscriptions. A department administrator can add accounts in their own department, but cannot create subscriptions.
• There is one account owner per account. Billing roles go to individual users, not to groups. From 16 November 2026, new billing role assignments must use work or school accounts.
• For an account owner or department administrator, seeing EA prices needs the view-charges policy turned on and the Azure Owner role. An enterprise administrator always sees them.

If your contract is a Microsoft Customer Agreement or a partner (CSP) agreement, the billing roles differ. I did not cover them here.

Who does what in the rollout

All roles below are my suggestion; the documentation gives roles only for new subscriptions.

Subscription owners should be told their duties: take full ownership of budget and resources, keep the subscription policy-compliant, and have their privileged access reviewed every quarter or year. The designated owner of a new subscription must be a user or service principal in the same directory, not a guest.

The 38 subscriptions as waves

My illustration of how the made-up manufacturer could sort them:

Do this: list your subscriptions by department, add the owner and where each subscription's Owner role comes from, and mark the ones nobody can name. The enterprise agreement shows which account created each subscription, which is a good first lead for finding the unowned ones (my suggestion).

What else a company must decide (my suggestion):

• Which subscriptions are the platform. The identity, connectivity and management subscriptions come from the platform build, not from the 38. Decide whether the hub stays in an existing subscription (my reading of the documented checks) or gets replaced.
• Corp or Online, per workload. Corp is for workloads that need private access to the hub; Online is for workloads that do not. The platform team and the workload owner decide each one, not the department.
• Departments stay in billing, not in the tree. Do not mirror the four departments as management groups. Keep cost by department in the Enterprise Agreement and in tags.
• Elevation with Privileged Identity Management. If the Global Administrator role is activated through it, activate first, turn the toggle on, and set the toggle back to No before you deactivate the role.

Take stock of what you have

You cannot judge what a policy or a move will do without knowing what runs. Fill one sheet with a row per subscription: owner, where the Owner role comes from, policy assignments, peering, identity needs, and "dependency unknown" where you do not know.

az login
az account list --output table

az account management-group list
az account management-group show --name '<groupId>' -e -r

az role assignment list --scope "/subscriptions/<subscriptionId>" --include-inherited --output json --query '[].{principalName:principalName, roleDefinitionName:roleDefinitionName, scope:scope}'

az policy assignment list --scope "/subscriptions/<subscriptionId>" --query "[].{Name:name, DisplayName:displayName, Id:id}" -o table

az extension add --name resource-graph
az graph query --graph-query 'Resources | project name, type | limit 5'

Plan the target and the owners

Plan the same design areas as for a new environment, in the same tenant. Four decisions matter most for an existing one.

What I could not find. The documentation gives no steps for merging an existing hub network into the new connectivity subscription, only checks (overlap, peering, routing). Treat the hub as a decision you test.

Who may call a stop: the rollback owner named for the wave may stop it at any time. Restarting needs the platform team and the workload owner to agree. The wave operator does the work, the platform team lead answers for the result, and security and finance are told.

A small example to follow

A second made-up company, small enough to follow every move: one tenant, six subscriptions, all under the root group.

app2-mixed moves as it is, with its test resources inside it, because moving individual test resources would mean moving its peered virtual network and every dependent resource together. Team 2 creates new test resources in dev-test instead, and the old ones retire later.

Build beside the old environment

Before you start. The builder needs the Owner role on the intermediate root, because the build creates groups and assigns access and policy (my reading). By default no one has access to the root group. A Global Administrator can grant it, as shown in before you start. Portal, Bicep and Terraform work in Azure public clouds; sovereign clouds need manual changes to Bicep or Terraform (Deploy Azure landing zones; choose how to implement it). The build creates the same billable platform resources as a new environment (cost note); the audit-only copies add none.

1. Deploy the landing zone in parallel, in the same tenant, by following the greenfield rollout post. This does not affect the existing environment. Check: the new groups appear in az account management-group list, and no existing subscription has moved.
2. Protect the top of the hierarchy. By default any user in the tenant can create a management group, and new subscriptions land under the root. Set a default group for new subscriptions, because the setting exists to give new subscriptions a more restrictive set of controls. The management groups design area page names a sandbox group as a good candidate for this default. My reading: a dedicated holding group with restrictive policy is also reasonable, because new subscriptions then start with strict controls until someone places them. Then turn on require authorization (in the portal, "Permissions for creating new management groups"). You need the Hierarchy Settings Administrator role or the same permissions. Use the portal (Management groups, root group, Settings) or the REST API; the documentation gives no az command: protect your resource hierarchy. Check: open the root group's Settings in the portal and confirm both.
3. Create the duplicate groups. Check: az account management-group show --name 'lz-brownfield' -e -r shows both children.
4. Assign the same policies to the copies in audit-only mode. Check: az policy assignment show prints "enforcementMode": "DoNotEnforce". If it prints Default, the policy will enforce.

az account management-group create --name 'lz-brownfield' --display-name 'Landing zones (duplicate)' --parent '<intermediateRootId>'
az account management-group create --name 'corp-brownfield' --display-name 'Corp (duplicate)' --parent 'lz-brownfield'
az account management-group create --name 'online-brownfield' --display-name 'Online (duplicate)' --parent 'lz-brownfield'

az policy assignment list --management-group '<landingZonesId>' --filter atScope()
az policy assignment create --name '<assignmentName>' --scope "/providers/Microsoft.Management/managementGroups/corp-brownfield" --policy <policyNameOrId> --enforcement-mode DoNotEnforce

az policy assignment show --name '<assignmentName>' --scope "/providers/Microsoft.Management/managementGroups/corp-brownfield"
az policy assignment update --name '<assignmentName>' --scope <scope> --enforcement-mode DoNotEnforce

Figure 3. How existing subscriptions meet the new groups.

See the effect in audit-only mode

A new assignment takes about five minutes to apply, and then evaluation begins. The result is a list of existing resources that meet a policy's condition, each non-compliant. Give each one an owner and a plan.

az policy state summarize -m 'corp-brownfield'
az policy state list -m 'corp-brownfield' --filter "(isCompliant eq false)"

Move in: pilot, then waves

The documentation gives no wave order and does not describe a pilot. In my suggestion, wave 1 is a pilot on one low-risk subscription, so the first mistake costs little. After it, the order is: development and test, then production, then subscriptions with complex network, regulatory or vendor dependencies.

Pick for the pilot: a subscription with a known owner, no production users, no hub peering and no resource move. In the small example, that is lab, going to Sandboxes. The duplicate groups cover only Corp and Online, so Sandboxes has no audit-only copy, and its policy set is less restrictive, not empty. List its assignments first (az policy assignment list --management-group '<sandboxesId>' --filter atScope()) and run the pilot only if none has a Deny effect that could block the owner's pipeline; otherwise set those to DoNotEnforce or pick another subscription.

What the pilot must prove (my suggestion):

• The placement command works and the portal shows the subscription under the right group.
• After the 30-minute wait, access works and the owner's pipeline runs.
• The compliance commands return data, and every non-compliant record has an owner.
• If a Deny policy applies, one test deployment that should be denied is denied.
• You can put the subscription back in its previous group (my reading; the documentation shows no rollback).

Exit criteria before wave 2 (my suggestion): every item above is proven and written down, no stop rule fired, you recorded how long the waits really took, and the rollback owner and the workload owner agree.

Place a subscription

A subscription that moves to a management group inherits all access and policy from its new parent. Its resource IDs do not change, so the move itself leaves the resources inside untouched.

az account management-group subscription add --name 'corp-brownfield' --subscription '<subscriptionId>'

Confirm in the portal (All services, Management groups) that it sits under the group. Changes can take up to 30 minutes to show; signing out and in is faster. Existing resources that break a policy show as non-compliant, and a person must fix them. New writes are judged in real time, so in my reading a redeploying pipeline can fail right after a move into a group that enforces. That is why the first stop is the audit-only copy.

az resource invoke-action --action validateMoveResources \
  --ids "/subscriptions/{subscription-id}/resourceGroups/{source-rg}" \
  --request-body "{  \"resources\": [\"<resourceId1>\", \"<resourceId2>\"],\"targetResourceGroup\":\"/subscriptions/{subscription-id}/resourceGroups/{destination-rg}\" }"

az resource move --destination-group <destination-rg> --ids <resourceId1> <resourceId2>

The runbook for each wave

The small example as a plan

In my reading, moving an existing subscription into a duplicate group (waves 2, 4 and 5) shows its compliance in audit-only mode; the approach page describes new subscriptions there, so confirm with your platform team.

How long the waits are

No page gives an overall schedule. These are the waits it gives (plus four hours if you move resources, and 30 to 60 days before a cancelled subscription is deleted):

Finish and retire

When the workload team and platform team bring compliance into the required state, move the subscription to the matching real group:

az account management-group subscription add --name '<corpGroupId>' --subscription '<subscriptionId>'

A subscription has one parent, so this replaces the duplicate group, and the full policies now cover it. For DINE and Modify, the policy-driven guardrails page enables them in stages: a reduced scope such as Sandbox first, then everywhere. Cancel subscriptions you no longer need and place them in Decommissioned; the repository's approach adds a holding period and a final approval.

Before its wave starts, tell each team its group, the policies that apply, its non-compliant resources and who fixes them. New subscriptions follow the subscription vending steps.

How new subscriptions get approved afterwards

Today, approval is an email. In the target state, a central group (the documentation calls it the Cloud Center of Excellence) builds the approval process, and new subscriptions come through a request flow. The documentation calls this subscription vending.

Figure 4. A new subscription, from request to workload.

Two settings protect the root: a default management group for new subscriptions, so one an account owner creates does not land under the root, and require authorization, so people cannot create management groups freely. Both are in "Build beside the old environment". They do not stop an account owner from creating a subscription outside this flow. That is a billing-role decision (my suggestion: keep the account owner role with the platform team's automation, and ask other account owners to use the request).

What comes next

A landing zone is not finished when the last subscription is in place. The next post covers keeping it up to date; the Enhance starting point is where you add controls.

Common mistakes

• Copying today's structure into management groups. Departments, regions and environments belong in subscriptions and tags.
• Leaving billing and access with different people and no shared list. The account owner who creates a subscription and the Owner who runs it can be different people. Keep one sheet that names both.
• Starting the next wave before the checks pass. The documentation gives no order; the pilot exit criteria and the checklist are the repository's guard against this.

From my own projects

I have not marked any item in the list above as something I saw in my own projects. I leave out project details.

The files in my repo

My repo is a learning implementation, and its own order and habits are the repository's approach, not the documentation's.

• Govern an existing Azure environment: a fictional company with 45 subscriptions, thirteen phases with evidence and an exit condition each. The repository's habits: inventory first, audit mode before enforcement, a low-risk pilot wave, a rollback path per wave: brownfield.md
• Ten short use cases: use-cases.md
• A template for recording a time-limited policy exception: policy-exemptions.md
• A ten-step decommissioning process, cancelling last: decommissioning.md
• Which services charge while idle: cost-and-safety.md

Sources

Microsoft Learn, checked October 2026: Transition an existing Azure environment to the Azure landing zone reference architecture · Scenario: Transition an environment by duplicating a landing zone management group · Manage Azure Enterprise Agreement roles