Two years in, your account tree's grouping axis is the wrong one — what does moving accounts to new parents actually cost?

## Why "no resources move" is the most expensive sentence in this decision Moving an account to a different parent changes one field: its position. No workload restarts, no data is copied, no address changes, no identity is re-issued. Everything that makes a migration slow is absent, which is why regrouping gets approved in a meeting — and why it is the change most often under-planned. The cost is not in the move. It is in everything that was quietly reading the shape. ## The four real costs **1. Effective permissions change, instantly and in both directions.** Inheritance is resolved per call, so the moment the parent changes, the set of policies above the account changes. That can go two ways, and both are defects: - The account **gains** a restriction and a job that has run for two years starts being refused. Because nothing restarted, the failure has no deployment to correlate with. - The account **loses** a restriction it was relying on, and nothing at all happens visibly. This is the worse one: a control silently stops applying, and only a review or an incident finds out. **2. The policies you did not touch change what they cover.** Reach is defined as the subtree of the attachment point, so when accounts leave a node, every policy still attached to that node now covers a smaller set — without being edited, reviewed or approved. The person who wrote "this applies to all our regulated accounts" wrote it about a subtree that no longer has the same members. This is the failure mode that survives the project and shows up in an audit a year later. **3. Reporting discontinuity.** Any report grouped by the tree — spend by node, ownership, budget variance — splits at the move date. Year-on-year comparison stops being meaningful for the moved accounts, and platforms differ in whether charges already recorded are restated under the new shape or left where they were incurred. Find out which before anyone is promised a clean series, because the finance audience is usually the one that asked for the regrouping. **4. The undeclared dependencies.** The tree is referenced by more than policy: access-review scopes, approval routing, budget owners, dashboards and filters, the names people navigate by, and whatever process issues new accounts into a particular node. Almost none of that is registered anywhere as depending on the hierarchy, so the discovery is done by breaking things. ## Depth, and what it costs later | tree shape | attachment precision | cost when reality changes | |---|---|---| | shallow, on a stable axis | coarse; some rules need per-account attachment | few or no moves | | deep, on a stable axis | precise at every level | moves only when the stable axis changes | | deep, on an unstable axis | precise today | a batch of moves after every reorganisation | Each extra level buys a finer attachment point and costs a move every time reality changes at that level. A deep tree on an unstable axis is the configuration that produces this question in the first place. ## How to do it, if you are going to 1. **Take an inventory of reach first.** For every policy attached anywhere, list the accounts it currently reaches. That list is your before-picture, and the only way to prove the move did what you intended. 2. **Move in batches**, smallest blast radius first, with the effective permissions of each moved account compared before and after and the audit trail of management API calls watched for denials. 3. **Re-examine the policies left behind** at every node accounts departed from, and confirm their now-smaller reach is still the intent. 4. **Tell the report consumers the date**, and agree what the series looks like across it. ## The alternative you should price first Often the right answer is not to regroup. If the restrictions you need can be attached per account or expressed as a condition on a label, and the axis you would move to is itself liable to change, then the cheaper posture is a **shallow tree on the most stable axis**, with the other axes carried as labels. A tree redrawn onto an unstable axis will be wrong again, and you will have spent the move twice. Regrouping earns its cost when the axis you would move to is genuinely permanent — a regulatory perimeter, a real separation of production from everything else — and when the rules you cannot currently attach in one place are the ones you are held to. ## The judgment being tested Whether you can price a change whose mechanical part is trivial. A lead who says "it is just a move" has priced the only part that is free, and a lead who says "it is impossible" has not looked. The defensible answer names the two silent failures — a control that stops applying, and a left-behind policy whose reach shrank — and proposes batches with a before-and-after comparison rather than a weekend.