Purview Integration during Merger and Acquisitions

Question

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; }

Hello,

We are currently in the process of merging with two other organizations and are looking to integrate our Microsoft Purview environments.

All three organizations have different sensitivity labeling schemes, and we would like guidance on the best approach to achieve a unified labeling strategy across the merged organization.

Specifically, should we create a new, common set of sensitivity labels for the combined organization and plan a phased transition for users? One of the organizations already has the majority of its documents labeled, so maintaining those existing labels during the merger is a key concern.

We are also looking for best practices to ensure that existing labels are preserved when the two additional organizations are onboarded into Purview, while still moving toward a consistent, unified labeling framework.

Any suggestions or if any one had already been a part of such a merger, please share your experience

derekmorgan2 · Answer

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&amp;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 HubIf 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 HubIf 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&nbsp;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.

nikkichapple · Answer

arunsekaran​ Before deciding on a unified labelling approach, the first question is what the target tenant looks like:

Are you consolidating into an existing tenant, or
Migrating all organisations into a new tenant?

Sensitivity labels are tenant‑scoped, so labels that look identical across tenants are not the same technically.
I’d strongly recommend starting with an impact assessment, covering questions such as:

Do any labels apply encryption, and if so, what are the encryption rules?
Are labels applied manually, automatically, or both?
What label policies exist (default labels, mandatory labelling, role‑specific policies)?
Are container sensitivity labels used for Microsoft 365 Groups, Teams, or SharePoint sites?
Are labels referenced in auto‑labelling, DLP, Insider Risk, retention, or other Purview controls?
Are there custom SITs, scripts, or tools that depend on specific label GUIDs?
Are labels enforced outside Microsoft 365 (for example via third‑party integrations)?

In an ideal scenario, you define the target labelling framework upfront, then map each source tenant’s labels to that target. If your migration tools support it, relabelling content during migration is the cleanest approach, particularly where one tenant already has large volumes of labelled data.
If content is migrated without relabelling, files may retain their original tenant’s label metadata, but users in the target tenant typically won’t be able to see or manage those labels, and label‑based policies won’t apply consistently.

arunsekaran · Answer

nikkichapple​ Thanks for taking the time to reply to my post.#We are looking to consolidate into an existing tenant.#Our labels don't apply encryption, and they are applied manually and it is used for just classification.#Our labels also are used in DLP policies that "blocks" or "block with override" users from uploading certain classification into ChatGPT or Gemini.

nikkichapple · Answer

arunsekaran​&nbsp;
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.
&nbsp;

arunsekaran · Answer

I confirmed that they are on E5 already, so one less problem to worry about.. haha

Forum Discussion

Purview Integration during Merger and Acquisitions

8 Replies