An enterprise administrator’s guide to migrating parent sensitivity labels to label groups while preserving classification, encryption, publishing policies, and existing protection.
Introduction
Microsoft Purview is modernizing sensitivity label management by replacing the classic parent-label structure with a simplified hierarchy based on label groups.
Organizations using the classic scheme may now see the following notification in Microsoft Purview:
Migrate to the modern label scheme. Start the migration process now to take advantage of a simplified label scheme.
Although the migration is designed to preserve existing classification and protection behavior, it introduces important administrative considerations.
Some parent labels become label groups directly. Others require additional sublabels to preserve their original settings and identities.
Microsoft also confirms that the migration is irreversible.
For security architects and Microsoft 365 administrators, the challenge is not simply completing the migration wizard. It is understanding what changes, identifying dependencies, and validating the resulting label architecture.
This guide explains Microsoft’s documented behavior and provides a practical assessment, migration, and validation framework.
1. Why Microsoft Is Modernizing Sensitivity Labels
The classic sensitivity label scheme uses parent labels and sublabels.
For example:
Confidential
- Employees
- Trusted Partners
- Restricted
The parent label organizes the hierarchy, but it can also have its own configuration and administrative dependencies.
This creates additional complexity.
The modern scheme replaces parent labels with label groups.
A label group organizes related sensitivity labels but is not itself a sensitivity label that users apply to content.
This separates the organization of labels from the classification and protection settings associated with individual labels.
Classic vs. modern scheme
| Capability | Classic scheme | Modern scheme |
|---|---|---|
| Hierarchy | Parent labels and sublabels | Label groups and sublabels |
| Organizational grouping | Parent labels | Label groups |
| Encryption | Configured on applicable labels | Configured on actual sensitivity labels |
| Content markings | Label configuration | Actual sensitivity label configuration |
| Publishing | Parent and sublabel relationships | Publish actual sensitivity labels |
| Label groups selectable by users | No | No |
| Administration | More complex hierarchy | Simplified grouping |
The purpose is to simplify administration without requiring organizations to redesign their entire classification taxonomy.
2. What Happens to Existing Parent Labels?
This is the most important technical aspect of the migration.
Microsoft distinguishes between parent labels that can become label groups directly and those that require an additional sublabel.
Scenario A — Parent label used only for grouping
Consider the following hierarchy:
Before migration
Confidential
- Employees
- Trusted Partners
If Confidential does not have configurations requiring preservation as an applicable sensitivity label, it becomes a label group.
After migration
Confidential — Label Group
- Employees
- Trusted Partners
The existing sublabels remain available.
Microsoft states that users should not experience changes to the existing hierarchy in their applications.
Scenario B — Parent label with its own configuration
Now consider a parent label that has its own encryption settings, content markings, auto-labeling configuration, or other properties requiring preservation.
Before migration
Confidential
- Employees
- Trusted Partners
After migration
Confidential — Label Group
- Confidential
- Employees
- Trusted Partners
Microsoft creates an additional Confidential sublabel.
The new sublabel preserves the original parent label’s identity and configuration.
This introduces an important consideration: the additional sublabel may become selectable by users.
Administrators must review whether that is intended.
3. Which Parent Labels Can Generate Additional Sublabels?
Microsoft documents several conditions that can cause a parent label to be converted into an additional sublabel.
These include parent labels with:
- Encryption settings.
- Content markings.
- Auto-labeling configurations.
- Advanced settings.
- Different scopes from their sublabels.
- Different publishing configurations.
The exact outcome depends on the original configuration.
Why this matters
Imagine an organization that uses Confidential only as a visible grouping for users.
However, the parent label also contains legacy encryption settings.
After migration, Microsoft may preserve those settings in an additional Confidential sublabel.
Users might then be able to select Confidential directly, rather than selecting Employees or Trusted Partners.
That could introduce unintended classification choices.
Recommendation: Review every parent label that the migration wizard identifies as requiring an additional sublabel.
4. What Happens to Existing Label GUIDs?
Every sensitivity label has a unique identifier.
These identifiers are important because Microsoft 365 services, scripts, and policy configurations can reference sensitivity labels by their GUIDs.
When Microsoft creates an additional sublabel to preserve an existing parent label, the new sublabel retains the original parent’s GUID.
The replacement label group receives a different identifier.
This helps maintain compatibility with existing configurations.
Practical example
An organization has a Confidential parent label with a GUID referenced by an internal automation.
During migration:
- A new Confidential label group is created.
- An additional Confidential sublabel retains the original label GUID.
- The existing automation can continue referencing that label identity, although hierarchy-dependent logic may require adjustment.
Architecture recommendation
Before migration, export the label inventory and record the GUIDs.
After migration, compare the resulting configuration.
Pay particular attention to scripts and applications that depend on parent-child relationships or display names.
5. What Happens to Existing Documents and Emails?
One of the most common concerns is whether previously labeled documents will lose their classification.
Microsoft designed the migration to preserve label identities and existing protection behavior.
The migration is not intended to automatically relabel every document or remove encryption.
For example, a Word document already protected by an existing sensitivity label should retain its applied label.
However, this does not eliminate the need for testing.
Recommended validation
Test representative content:
- Word documents with sensitivity labels.
- Excel workbooks with encryption.
- PowerPoint presentations.
- Supported labeled PDF documents.
- Labeled email messages.
- Documents shared with external collaborators.
Confirm that existing classifications remain valid and authorized users can still access protected content.
Important: The primary migration risk concerns label administration and newly created sublabels, not a general loss of labels already applied to content.
6. What Happens to Publishing Policies?
Publishing policies control which sensitivity labels users can access.
Microsoft states that existing publishing policies continue to work after migration.
However, additional sublabels created during migration can introduce new choices for users.
Example
Before migration, users select:
Confidential → Employees
After migration, they might also see:
Confidential → Confidential
This happens when Microsoft creates an additional sublabel from the original parent.
If the new sublabel is included in a publishing policy, users may be able to select it.
Recommended actions
Before migration:
- Inventory publishing policies.
- Identify parent labels currently included.
- Review the users and groups receiving each policy.
- Identify additional sublabels proposed by the migration wizard.
After migration:
- Review the migrated publishing policies.
- Verify which labels are visible to users.
- Unpublish unwanted additional sublabels where appropriate.
- Confirm default label behavior.
- Validate mandatory labeling and downgrade justification settings.
Microsoft provides PowerShell guidance for identifying and adjusting publishing policies after migration.
7. What Happens to Encryption and Content Markings?
The modern label scheme separates label organization from protection settings.
Label groups do not apply encryption or content markings.
Those capabilities remain associated with actual sensitivity labels.
Where a parent label contains protection settings that must be preserved, Microsoft can create an additional sublabel carrying the original configuration.
Potential side effect
Suppose the original Confidential parent label applies encryption.
After migration, the additional Confidential sublabel retains that encryption configuration.
If users can now select that label, they may apply encryption in scenarios where they previously selected a different sublabel.
Recommended validation
Confirm:
- Encryption settings.
- Authorized users and groups.
- External collaboration permissions.
- Content markings.
- Access to previously encrypted documents.
- Behavior of newly labeled documents.
Do not delete newly created sublabels without assessing whether they are referenced by existing content or services.
8. What Happens to DLP and Auto-Labeling?
Microsoft Purview DLP policies and auto-labeling configurations may reference sensitivity labels.
The migration is designed to preserve label identities, but organizations should validate dependent policies.
DLP
Review policies using sensitivity labels as conditions.
Verify that:
- Label references remain correct.
- Detection works as expected.
- Exceptions are preserved.
- Enforcement actions remain effective.
Auto-labeling
Review policies that apply sensitivity labels automatically.
Verify that:
- The intended labels remain targeted.
- Label priority is appropriate.
- Classification conditions still work.
- Encryption behavior remains correct.
PowerShell and API integrations
Review custom scripts, Microsoft Graph integrations, and other automation that depend on label hierarchy.
Configurations based on GUIDs may continue working, but scripts that assume the classic parent-label structure may need updating.
9. What Are the Actual Migration Risks?
| Risk | Potential impact | Recommended mitigation |
|---|---|---|
| Additional sublabels | New user-selectable labels | Review publishing policies |
| Naming conflicts | Confusing hierarchy | Resolve conflicts in the wizard |
| Parent label configuration | Additional labels with protection settings | Review migrated label configuration |
| Encryption | Unexpected protection if a new label is selected | Test access and permissions |
| Automation dependencies | Hierarchy-dependent scripts may fail | Validate integrations |
| Label publishing | Unintended classification choices | Test with representative users |
| Changes during migration | Configuration inconsistencies | Freeze administrative changes |
| Irreversible migration | No direct return to classic hierarchy | Test before production |
These are potential risks, not guaranteed outcomes.
Microsoft’s documented expectation is that existing sublabels and the familiar end-user hierarchy continue functioning.
10. Pre-Migration Assessment
A structured assessment should cover five areas.
Label inventory
Document label names, GUIDs, hierarchy, scopes, priority, encryption, content markings, and advanced settings.
Publishing policies
Identify which labels are published, to whom, and with what default or mandatory labeling behavior.
Dependent configurations
Review DLP, auto-labeling, scripts, APIs, and other integrations referencing sensitivity labels.
User experience
Identify additional sublabels that might appear and determine whether they should be published.
Change management
Prepare a test plan, change window, configuration export, approval process, and remediation strategy.
Recommended deliverable: Modern Sensitivity Label Scheme Migration Readiness Assessment.
11. Step-by-Step Migration Procedure
Step 1 — Open Microsoft Purview
Navigate to:
Microsoft Purview → Information Protection → Sensitivity labels.
Select Get started in the modern label scheme migration banner.
Step 2 — Review the proposed scheme
Use the migration wizard to review how existing parent labels and sublabels will be transformed.
Step 3 — Identify additional sublabels
Examine parent labels that will generate additional sublabels.
Review their protection settings and publishing behavior.
Step 4 — Resolve naming conflicts
Address any naming conflicts identified by the wizard.
Step 5 — Export the proposed scheme
Download the CSV file describing the proposed modern hierarchy.
Keep it as part of the migration evidence.
Step 6 — Validate in a test tenant
Microsoft recommends testing the migration in a representative tenant because the process is irreversible.
Step 7 — Execute migration
Start the migration after approval.
Microsoft states that the process generally takes minutes to an hour, but administrators should allow up to 24 hours.
Avoid label configuration changes while the migration is in progress.
Step 8 — Validate the resulting configuration
Review label groups, sublabels, GUIDs, publishing policies, encryption, DLP dependencies, and automation.
Step 9 — Remediate additional sublabels
Where appropriate, adjust publishing policies so users see only intended labels.
12. Migration Testing Matrix
| Test scenario | Expected result |
|---|---|
| Existing labeled Word document | Existing label remains valid |
| Existing encrypted file | Authorized access continues |
| Existing sublabel | Available to intended users |
| Additional migrated sublabel | Publishing matches intended design |
| Default label | Existing behavior continues |
| Mandatory labeling | Expected behavior |
| Label downgrade justification | Expected behavior |
| DLP policy referencing labels | Detection and enforcement work |
| Auto-labeling policy | Correct target label |
| PowerShell automation | Correct label identification |
| External collaboration | Authorized sharing continues |
Document the test evidence and obtain approval before closing the change.
13. Rollback and Remediation
Microsoft confirms that the modern label scheme migration is irreversible.
There is no supported one-click rollback to the classic hierarchy.
Therefore, the migration plan should focus on prevention and remediation.
Before migration:
- Export label configurations.
- Record label GUIDs.
- Document publishing policies.
- Review proposed additional sublabels.
- Test in a representative tenant.
- Obtain change approval.
After migration:
- Adjust publishing policies where needed.
- Review incorrect label configurations.
- Validate integrations.
- Investigate unexpected encryption or access behavior.
- Update administrative procedures and documentation.
Remediation is not the same as reversing the migration.
14. Recommended Project Plan
| Phase | Illustrative duration | Deliverable |
|---|---|---|
| Current-state assessment | 2–3 days | Label inventory |
| Architecture review | 1–2 days | Target hierarchy and risk assessment |
| Test migration | 1–3 days | Validation evidence |
| Production preparation | 1 day | Approved change plan |
| Migration | Allow up to 24 hours | Migration record |
| Post-migration validation | 1–2 days | Validation report |
| Remediation | As required | Final sign-off |
These are consulting planning estimates, not Microsoft-prescribed durations.
15. Production Go/No-Go Checklist
- Existing label hierarchy is documented.
- Label GUIDs are recorded.
- Applicable parent labels are identified.
- Proposed additional sublabels are reviewed.
- Publishing policies are documented.
- Encryption and content markings are assessed.
- DLP and auto-labeling dependencies are reviewed.
- Automation dependencies are validated.
- Proposed scheme CSV is exported.
- Test tenant migration is completed.
- Configuration freeze is approved.
- Post-migration validation is prepared.
- Remediation responsibilities are assigned.
16. Rollout Timeline and Automatic Migration
Microsoft announced the modern sensitivity label scheme through Microsoft 365 Message Center notification MC1111778.
The rollout includes several important milestones.
- New tenants have used the modern scheme since October 1, 2025.
- Tenants without applicable parent labels can be migrated automatically.
- Tenants with applicable parent labels receive a manual migration option for a limited period after general availability.
- Microsoft plans eventual automatic migration of remaining tenants.
Organizations should therefore use the manual migration opportunity to review their hierarchy and dependencies before automatic migration becomes applicable.
The exact rollout status should be confirmed against current Microsoft announcements and the tenant’s available migration experience.
Conclusion
The modern Microsoft Purview sensitivity label scheme simplifies administration by replacing traditional parent labels with label groups.
Microsoft designed the migration to preserve existing label identities and protection behavior.
For most users, existing sublabels and the familiar label hierarchy should continue working.
However, parent labels with specific configurations can generate additional sublabels, potentially introducing new selectable labels and publishing-policy considerations.
Because migration is irreversible, administrators should assess their current hierarchy, review the proposed changes, validate dependencies, and test the resulting configuration before proceeding in production.
The key to a successful migration is not merely converting parent labels into groups. It is preserving classification integrity while simplifying the sensitivity label architecture.
Official Microsoft Documentation
- Migrate parent sensitivity labels to label groups
- Learn about sensitivity labels
- Create and publish sensitivity labels
- Automatically apply sensitivity labels
