The migration to group-based licensing is conceptually simple: assign the license to a group, confirm inheritance, remove the direct grants. The risk is entirely in the third step, because removing a direct grant is only safe once you can prove the user is a direct member of the licensed target group.
The safe sequence#
Run the migration as an overlap, never as a swap:
- Assign the SKU to the target group and let processing complete.
- Verify every intended user now holds the license from both sources.
- Check for assignment errors: users where the group grant failed and the direct grant is still the only coverage.
- Only then remove direct assignments, in batches, verifying after each.
Where migrations actually fail#
Two places: users who are not direct members of the target group, including anyone expected to be covered through a nested group, which group licensing ignores, and users whose group assignment failed quietly, for reasons like a missing usage location. Both look fine while the direct grant remains and lose service the moment cleanup removes it. The migration's real work is enumerating these two populations before touching anything.
The second failure is the unfinished ending: the overlap window becomes permanent because nobody can prove which direct grants are now redundant. Years later the tenant runs both models everywhere, which is the confusion the migration meant to end.
VisualizerEngine
How VisualizerEngine de-risks it
Duplicate detection lists exactly the users holding both a direct and group source for the same SKU, which is the safe-to-clean population, and license analytics shows who is covered by only one source and which one. Removal impact analysis previews each cleanup batch, and snapshots before and after prove the migration changed only what it claimed to.