---
title: "Discussion on \"The A-Z of Azure: M is for Management Groups\" | Hashnode"
description: "Discussion on \"The A-Z of Azure: M is for Management Groups\". How to organise your Azure subscriptions and simplify RBAC, Azure Policy, and cost management across your estate."
url: "https://hashnode.com/posts/atozazure-management-groups/6ad7215ff2efc5f780f34f0e"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [The A-Z of Azure: M is for Management Groups](https://blog.atozazure.com/atozazure-management-groups?utm_source=hashnode&utm_medium=feed)

How to organise your Azure subscriptions and simplify RBAC, Azure Policy, and cost management across your estate.

Oct 20 · 5 min read · blog.atozazure.com  
Read the article

-   [#azure](https://hashnode.com/tag/azure)
-   [#atozazure](https://hashnode.com/tag/atozazure)
-   [#microsoft](https://hashnode.com/tag/microsoft)
-   [#cloud-computing](https://hashnode.com/tag/cloud-computing)
-   [#devops](https://hashnode.com/tag/devops)
-   [#security](https://hashnode.com/tag/security)

## Written by

[Daniel Powley](https://hashnode.com/@danzure)

@danzure · London, United Kingdom

  
[View profile](https://hashnode.com/@danzure)

Senior Cloud Engineer & Solutions Architect

I'm an UK-based 'Senior Cloud Engineer' and certified solutions architect with ten years experience across the IT industry. My focus is on sharing my own knowledge and experiences with the wider cloud community to help inspire and teach others about Azure.

## Responses 1

Markdown supported · ⌘↵ to post

[Oct 20](https://hashnode.com/posts/atozazure-management-groups/6ad7215ff2efc5f780f34f0e/comment/6ad74e16e3659a7aed89c320)

One thing that can get tricky with management groups is moving an existing subscription between branches of the hierarchy.

Imagine moving a production subscription from `Corp` to a new `PCI` management group to meet stricter compliance requirements. The subscription doesn't just get a new parent; it inherits a different combination of Azure Policy assignments and RBAC permissions. If custom role definitions or inherited access assignments are tied to the old hierarchy, the move can also fail or leave the workload with unexpected access.

I'd want a pre-move validation step that compares the effective policies and permissions before and after the move, then checks compliance once the new inheritance takes effect. Have you considered adding that kind of impact analysis to the Management Group Planner, rather than limiting it to validating the tree structure itself?