Everyone agrees the twin groups should be one; nobody merges them, because a merge is only safe when both differences are known: what each group grants that the other does not, and who each contains that the other does not. The merge itself is mechanical once those two lists exist.
The safe sequence#
Five steps, in order, with verification between:
- Difference the grants: every access, application, and license assignment unique to each twin.
- Difference the members: who is in one but not the other, including transitively.
- Choose the survivor and move the unique grants onto it deliberately, one by one.
- Migrate the unique members, then let assignments settle before proceeding.
- Retire the loser: remove it from every parent group first, then delete.
Where merges go wrong#
The classic failure is merging memberships while forgetting a grant unique to the retired twin, discovered as an access outage days later. The second is deleting a group still nested somewhere load bearing. Both are exactly the differences step one and step five exist to catch.
VisualizerEngine
How VisualizerEngine does it
Overlap detection finds the twins and quantifies the overlap, the hierarchy shows each twin's unique grants and parents, and what-if simulation previews the merge's full blast radius before any step runs. Snapshot diffs verify each stage completed as planned.