During a Microsoft 365 tenant-to-tenant migration, sensitivity labels can be dropped or become inaccessible due to several technical and configuration-related challenges.
Sensitivity labels, part of Microsoft Purview Information Protection, are used to classify and protect emails, files, and other content by applying metadata, encryption, and access controls.
When content is migrated between tenants, the following issues may cause labels to be dropped or not function as expected in the target tenant:
- Encryption Key Mismatch: Sensitivity labels that apply rights-management-based encryption (e.g., using Azure Information Protection) rely on tenant-specific encryption keys. These keys are not automatically transferred during migration. If a file or email is encrypted with the source tenant’s key, users in the target tenant may be unable to access it unless the keys are migrated or the encryption is removed before migration. If the source tenant is decommissioned, the encryption keys may become unavailable, rendering protected content inaccessible.
- Label Configuration Differences: Sensitivity labels are defined and published in the Microsoft Purview compliance portal, and their configurations (e.g., encryption settings, access permissions) are tenant-specific. If the target tenant does not have identical labels (matching GUIDs, names, and settings), the labels may not be recognized or applied correctly after migration. Renamed labels or differing label hierarchies can cause mismatches, leading to labels being dropped or misapplied.
- Lack of Automated Label Migration: Most migration tools do not natively support the transfer of sensitivity labels, especially those with encryption. Without specialized tools (e.g., Quest On Demand Migration or ShareGate), labels may need to be manually reapplied or decrypted in the source tenant and relabeled in the target tenant, which is time-consuming and error-prone. This is particularly challenging for large-scale migrations involving thousands of documents or emails.
- Policy and Publishing Issues: Sensitivity labels are distributed through label policies that specify which users or groups can access them. If these policies are not replicated in the target tenant, labels may not appear in Office apps or may fail to apply correctly. Additionally, label policy synchronization can take time (up to 24 hours for containers like Teams or SharePoint sites), and misconfigurations can result in labels being unavailable.
- Unsupported Scenarios: Labels applied to specific content types (e.g., Power BI artifacts or template apps) may not be supported in the target tenant if the necessary configurations (e.g., Microsoft Purview Information Protection Sync Service) are not enabled. For example, Power BI requires specific licenses and settings to support sensitivity labels, and these may not be configured in the target tenant.
- SharePoint and OneDrive Challenges: Files stored in SharePoint or OneDrive with sensitivity labels may retain their encryption but lose their association with the target tenant’s label policies. This can prevent users from opening files unless the labels are removed or reassigned using tools like the Unlock-SPOSensitivityLabelEncryptedFile cmdlet or the assignSensitivityLabel Graph API. These processes can be costly (e.g., metered API calls) and complex to automate.
Mitigation Strategies
- Pre-Migration Planning: Map sensitivity labels between source and target tenants, ensuring identical configurations (GUIDs, names, encryption settings). Use tools like ShareGate or Quest On Demand Migration to automate label preservation.
- Decrypt Before Migration: Remove encryption from files using PowerShell cmdlets (e.g., Unlock-SPOSensitivityLabelEncryptedFile) or Microsoft Graph APIs to avoid key mismatches, then reapply labels in the target tenant.
- Use Specialized Migration Tools: Tools like ShareGate can preserve labels by integrating with Microsoft Information Protection APIs, automatically mapping and reapplying labels during migration.
- Reconfigure and Republish Labels: In the target tenant, recreate and publish sensitivity labels and policies to match the source tenant’s setup. Test with a small group of users before full deployment.
- Post-Migration Validation: After migration, verify that labels are applied correctly and that users can access protected content. Use PowerShell to check label policies (e.g., Get-LabelPolicy) and audit logs to identify issues.
Without proper planning and tools, sensitivity labels may be dropped or rendered unusable, risking data security and compliance. Specialized migration tools and careful configuration alignment are critical to preserving labels during tenant-to-tenant migrations.
