Forum Discussion
Purview Integration during Merger and Acquisitions
Hey, arunsekaranâ! đ There isnât a native âtenant-to-tenant migrationâ for Purview sensitivity labels as objects. Labels are tenant-scoped (label IDs/GUIDs and publishing/encryption constructs donât port cleanly), so in M&A you usually pick a strategy based on how labels are being used.
- If labels apply encryption / user-defined permissions: Microsoftâs common patterns are (1) keep the source tenant available for legacy protected content during the transition, (2) plan a support-led key/TPD move, or (3) ârekeyâ content (decrypt in source â migrate â relabel/encrypt in destination). See: Mergers and Spinoffs | Microsoft Community Hub
- If labels are classification/markings only: the destination tenant wonât automatically interpret the source label GUIDs, so the typical approach is to recreate a common label taxonomy in the destination and then re-label content after migration using portable signals (e.g., document properties/content markings + auto-labeling). See: Sensitivity Auto-labelling via Document Property | Microsoft Community Hub
- If you only need label interpretation/mapping (not preserving protection), thereâs an advanced mapping option using âlabelByCustomPropertiesâ (labeling-only). See: Walkthrough for AIP labelByCustomProperties Advanced Feature | Microsoft Community Hub
Question for you: Are most of your existing labels encryption-enabled (especially user-defined permissions), or is this primarily classification/markings today? That detail usually determines whether âbridge temporarilyâ (keep source tenant) vs ârelabel/rekeyâ is the right primary approach.
DerekMorgan2â Our labels doesn't apply Encryption, and it is primarily used for marking or classifying. Our labels are applied manually and doesn't use any auto-labelling policies.
I am still not sure with the other organizations labelling practices.
arunsekaranâ, depending on the labelling practices from other organizations, I would definitely go by what nikkichappleâ replied earlier and perform an impact assessment on the other organizations. From experience, either the other organizations will adopt your labelling practices, if they have none or have weak labelling practices, or you'll absorb their practices if they strengthen your labelling foundations đ
That said, there is migration tooling available from Quest on Demand, that migrates content protected by Purview via sensitivity labels: https://support.quest.com/on-demand-migration/kb/4379126/sensitivity-labels-and-encryption-migration-of-protected-content-for-mail-sharepoint-and-onedrive
Thanks! I'll be sure to check that out
One additional factor thatâs often overlooked is licensing in the target tenant.
If the merged tenant is licensed with Business Premium or A3/E3/G3, you are limited to manual sensitivity labelling by end users. Serviceâside autoâlabelling for data at rest (SharePoint and OneDrive) requires higherâend compliance licensing (for example, E5 or equivalent addâons).
This makes the migration approach even more critical. Where automatic labelling at scale isnât available postâmigration, it becomes essential that:
- Your migration tooling preserves or reapplies labels during migration, and
- Labels are already present on the content as it lands in the target tenant
Otherwise, you risk ending up with large volumes of unlabeled data and no practical way to remediate that at scale without major user effort.
In short, licensing directly influences your viable migration strategy, and should be treated as a core input when designing the target labelling model and migration approach.
