On default, the migration of protected content will result in content losing the relevant metadata related to the sensitivity labels applied to a file / email. Encrypted content will always link back to the decryption key on the source environment, resulting in the end user having to enter their credentials of the source account on the target tenant to access the migrated file / email. Once the source tenant is discontinued / turned off or access for a migrated user is removed, the encrypted files / emails will no longer be accessible resulting in a potential data loss scenario.
On Demand Migration has been enhanced with new features to support the migration of such protected content between source and target. Organizations no longer have to remove labels and encryption from content on the source in order to fully support the migration. On Demand Migration provides new options to match/map labels from source to target, remove the labels and encryption during the migration process and reapply labels and encryption on the target once the migration completes.
Feature Flag migration.sensitivitylabels.allowAccess must be enabled for the customer Organization. A Support Case should be raised with Quest Support to request the Feature Flag to be enabled for their ODM Organization.
Once the Feature Flag is enabled, when connecting a new Tenant and granting consents to the ODM Applications, you will find new consents listed:
AIP protected content migration – Read, which is used for source tenants.
This consent requires the following permissions to be granted to:
Content.SuperUser – Read all protected content for this tenant
UnifiedPolicy.Tenant.Read – Read all unified policies of the tenant
AIP protected content migration – Write, which is used for target tenants.
This consent requires the following permissions to be granted to:
Content.Writer - Create protected content
UnifiedPolicy.Tenant.Read - Read all unified policies of the tenant.
Once the appropriate applications have been granted consent to, the migration user will find a new card on the migration project dashboard called “Sensitivity Labels”. In order to migrate labels between tenants, it is important to follow the exact workflow:
Discover Sensitivity Labels on the source and target
Match Sensitivity Labels either based on selection or from an imported file
Migrate content using the new Sensitivity Labels option from the migration tasks configuration wizard in the appropriate workload
More information can be found in our official documentation and user guides on Quest.com.
It is important to understand certain limitations and risks when migrating sensitivity labels.
Quest On Demand Migration does not migrate the actual labels from source to target but reapplies these labels as part of the migration process. The actual labels and policies associated to the labels must be preexisting on the target tenant prior to discovery and matching.
After creation of labels on the target tenant, it can take up to 24 hours for these to be discoverable by On Demand Migration, this is simply due to provisioning and processing handled by Microsoft. Similar time constraints apply with the provisioning of Teams and Groups and OneDrives.
Migration tasks where the processing of sensitivity labels has been configured, will be impacted for the overall performance of the migration due to the Azure Information Protection API, which means throughput will be lower for protected content.
Additionally, whilst SharePoint is able to identify content with labels applied prior to migration, Mail and OneDrive must check every file / email in scope of the migration task for applied sensitivity labels and then process them accordingly. The difference is due to APIs used for the migration process. SharePoint receives this information as part of the metadata returned by the SharePoint Migration Export (AMR) API. Mail and OneDrive tasks will have to inspect every item with the MIP SDK prior to processing.
