Migrating to Microsoft Purview sensitivity label groups: what I learned
- 6 minutes ago
- 7 min read
Introduction
This is one of those Microsoft Purview changes that looks fairly minor at first, then turns out to matter quite a lot.
For years, sensitivity labels used the old parent and child model inherited from the earlier Azure Information Protection days. It worked, mostly, but it always felt a bit rigid. Once labels were heavily used, changing the structure later could get awkward very quickly.
Microsoft is now replacing that model with standalone labels and sensitivity label groups, which is clearly the long-term direction going forward. According to Microsoft, label groups reduce complexity, simplify administration, and make it easier to move labels around without losing configuration.
Honestly, I like the idea.
The old parent and sublabel structure never felt especially flexible, and label groups are a much cleaner concept overall.
This post is a high-level overview of the changes, how the migration works, what Microsoft recommends reviewing beforehand, and what I personally observed after testing this in a couple of demo tenants and a few production environments.
This is not a step-by-step migration guide. I’m deliberately keeping this one higher level. If people want a deeper walkthrough covering the exact migration steps, checks to perform beforehand, rollback considerations, DLP validation, policy review, or post-migration troubleshooting, let me know and I’ll put together a separate detailed guide.
And I’ll say this upfront, my experience with the migration has been mixed.
Table of contents
TL;DR
Microsoft is replacing the old parent and child sensitivity label model with sensitivity label groups. For users, the experience is meant to look largely the same. For admins, the big win is flexibility, because labels can be moved into and out of groups more easily and the grouping object itself is much simpler than a parent label used to be. Microsoft also warns that migration is irreversible, recommends testing first, and says some parent labels can become both a label group and a new label after migration if those parent labels were doing more than just grouping.
My own view is this: I like where Microsoft is going with label groups, but I would be very cautious about migrating in production if labels are widely adopted and you have a large volume of already-labelled content. In my own testing, and in a couple of production environments, I saw temporary disruption after migration, including labels not being available to users for up to 72 hours in the worst case, and DLP conditions using sensitivity labels not behaving as expected for roughly 48 hours. That part is my own observation, not Microsoft documentation, but it is exactly why I would plan this carefully and not treat it like a harmless quick tidy-up.
What sensitivity label groups are
The short version is that Microsoft is moving away from parent labels with sublabels and toward a modern scheme built around standalone labels and label groups.
Microsoft’s documentation says the old two-tier hierarchy used parent labels to organise sensitivity labels, but this added complexity because parent labels looked like normal labels in configuration while behaving differently when published. With the new model, label groups replace parent labels. They keep only the settings needed for grouping, such as name, description, colour, and priority, and you publish the labels inside the group rather than the group itself.
That is the important shift.
The grouping object becomes just that, a grouping object. Not a weird half-label, half-container that looks configurable like everything else.
And honestly, that makes a lot more sense.
Why Microsoft is changing this
The old model was strict in a way that made future changes harder than they should have been.
If you built a parent and child structure years ago and then your business changed, reorganising that structure later was never especially elegant. The newer architecture fixes a lot of that. Labels can now be moved into and out of groups, and the reason this matters is that the label itself keeps its settings intact when you move it. The goal is simpler administration and reduced deployment complexity.
That is the part I genuinely like.
A good label taxonomy should be able to evolve as the business evolves. Anything that makes that easier is a good thing.
Microsoft says that for new tenants from 1 October 2025, the modern scheme applies automatically. For existing tenants, migration can be manual when the banner is available, and broader migration timing has been communicated separately through the message centre.
How the migration works
If your tenant is eligible, you will see a banner in the Purview portal under:
Solutions -> Information Protection -> Sensitivity labels
From there, you can start the migration workflow, review what the new scheme will look like, and download the proposed structure as a CSV before you commit. This is the moment to review the before-and-after carefully, especially if any parent labels are going to become both a label group and a new sublabel with the same name.
That specific scenario happens when the old parent label was doing more than just acting as a container. Microsoft lists reasons such as:
the parent label still having protection settings
visual markings
client-side auto-labelling
advanced settings applied with PowerShell
scope differences between the parent and its sublabels
unusual publishing situations where the parent was selected without its sublabels
Once you click Migrate, that is it. Microsoft is very clear that the migration is irreversible.
What to review before you migrate
The most useful part of Microsoft’s migration flow is the preview of the new scheme.
Before you do anything, I would check:
how many labels and groups you will end up with
whether any parent labels are about to become both a group and a label
whether that new label should stay published afterwards
whether your publishing policies need adjusting
whether your priority order still makes sense after the move
Microsoft explicitly recommends reviewing labels before migrating so you can reduce or remove applicable parent labels that would otherwise create new sublabels you might not need. Microsoft also says that if you decide a newly created sublabel should not be visible to users, you can unpublish it manually or by script.
That last bit matters more than it sounds.
If a former parent label suddenly becomes an actual selectable label after migration, that can create confusion very quickly if users see it and start applying it to files or emails when it was never meant to be used that way.
What changes for admins and end users
For end users, Microsoft says the goal is that things should look and behave much the same. Labels still appear grouped in apps in a similar way, and the applied label structure still makes sense from the user side. The real change is more on the admin side.
For admins, the differences are more obvious:
you now create either a label or a label group
you can move labels into and out of groups
label groups themselves have fewer settings than the old parent labels (and label groups cannot be applied to items, containers, or schematised data assets)
you no longer need to think about publishing the parent label in the same old way because groups are just the grouping layer now
This is cleaner. It also feels like Microsoft is finally removing one of the last more obvious leftovers from the older AIP design approach.
My real-world observations after migrating
I have now completed this migration in a couple of my own demo tenants and in a couple of client production environments that were brave enough to let me do it.
And honestly, the results have been mixed.
On the positive side, the actual migration process itself is fast. In every case I tested, the wizard moved through in seconds, which lines up with the general feel of Microsoft’s process. The portal side of the conversion is not the hard part.
The harder bit is what happened afterwards.
In my testing, the migrated labels were not consistently available to end users straight away. In the worst case, it took up to 72 hours before things looked properly healthy again. In most cases it was less than 48 hours, but still long enough to be very noticeable in a production environment.
I also noticed that any DLP policy using a sensitivity label as a condition did not behave as expected for roughly 48 hours after label migration.
And the frustrating part was that the logs and errors were not particularly helpful. I did not get anything with useful context. The general pattern was just that the service looked unavailable, users were unable to apply labels to new content, and clicking a label simply did nothing.
One example that stood out was with PowerPoint. A user had a file open with an existing label already on it, let’s say General, and suddenly they could no longer edit the file properly. After a while, they were prompted to select a label again, as if the app had lost confidence in the label state and wanted to re-evaluate it.
That is obviously not a fun experience if labels are heavily used in your environment.
To be crystal clear, those are my own observations from testing and real-world migration work. I am not saying Microsoft documents this as expected behaviour. I am saying I have seen enough disruption myself that I would treat the migration with caution.
Why I would be careful in production
I completely understand the benefits of moving to label groups and standalone labels. It is a better design. It is cleaner. It is more flexible. It is where Microsoft is clearly heading.
But I would still be very careful about migrating in production, especially if:
labels are widely adopted
you have thousands of already-labelled documents
labels drive DLP logic
labels are embedded in mature user workflows
you have very little tolerance for temporary disruption
Microsoft recommends testing first in a tenant that matches production and explicitly says the migration is irreversible. Microsoft also says some tenants will continue to get migration through a staged rollout, with manual migration for some and automatic migration for others over time.
My personal advice would be:
test in a like-for-like non-production tenant first
review the proposed new scheme carefully
check publishing policies straight after migration
watch for newly created selectable labels that used to be parents
plan the work for the end of the day
assume there may be a period where apps and policies need time to catch up
Personally, if there is no urgent business reason to migrate immediately, I would probably wait until the migration process feels a bit more mature and predictable.
Conclusion
I do think sensitivity label groups are the right direction.
The old parent and child model always felt more rigid than it needed to be, and this new approach is cleaner and easier to work with. But just because the design is better does not mean the migration is something I would rush in production.
My overall view is fairly simple. Understand the new model properly, review the impact on publishing policies, test carefully, and be realistic about the possibility of temporary disruption afterwards.
In other words, yes, move forward, but do it with your eyes open.