Purview and DLP don't move with a tenant. You rebuild them.
Someone on the project asks, "and we're bringing over the DLP policies and the labels, right?" The honest answer is no. Compliance configuration is stitched into the tenant it was born in, and the target has never heard of it. You recreate it, and you plan for the content that arrives already stamped by a tenant that no longer owns it.
New to cloud? CAMPUX is a free, build-first course. Start here →
This is part of the Azure tenant-to-tenant migration guide, and it is the piece people underestimate most. Mailboxes and files copy across with a tool. Microsoft Purview compliance configuration does not. Data loss prevention policies, sensitivity labels, retention policies and labels — all of it is tenant-scoped, and Microsoft ships no native feature that lifts it from one tenant into another. What moves is the content. The rules that governed that content stay behind, and you rebuild them in the target by hand or with a third-party tool. Treat that as a design task, not a copy step.
Why Purview config is per-tenant in the first place
A DLP policy is not a portable file. Microsoft's own description is that once you create a policy it is stored in a central policy store and then synced to the content sources inside that tenant — Exchange, SharePoint, OneDrive, the Office desktop apps, Teams. That store belongs to one tenant. The policy references that tenant's users, groups, sites, and sensitive information types. There is no export-and-import that reconstitutes the same objects in a different directory. So when you consolidate two tenants into one, you sit down with the source policies open on one screen and rebuild each rule — its conditions, its locations, its actions — in the target Purview portal. Tedious, but at least it is honest work you can plan.
The content crosses the border. The rulebook that governed it does not.
The sensitivity-label ID problem
Labels are where teams get surprised. A sensitivity label is a tenant-specific object with its own identifier, and Microsoft is explicit that the label is stored in clear text in the metadata of each file and email — "the label identification that's unique to your organization becomes the basis for applying and enforcing policies." Read that carefully. The stamp on the document is not the word "Confidential." It is an ID that only the source tenant ever issued. Move that document to the target and it arrives carrying an identifier the new tenant has never seen. The target has no label with that ID, so it does not recognize the classification, and your carefully-built reporting shows a sea of unlabeled content.
The fix is not a switch you flip. You plan matching labels in the target — same names, same protection intent — publish them, and then, where classification actually matters, re-label the migrated content in the target so it carries an ID the new tenant owns. For a handful of labels and a small estate you do this by hand. At scale there is no native path, which is why third-party tools from vendors like Quest and ShareGate exist to map source labels to target labels and reapply them during the move.
When a label applies encryption, the protection is bound to the source tenant's rights management. The usage rights name specific users and groups from the source directory, and the keys belong to that tenant. Copy those encrypted files across as-is and users in the target can find themselves locked out — the accounts and keys the file trusts no longer exist for them. Encrypted content has to be handled deliberately: decrypt or re-protect it as part of the move, with the right permissions, not discovered as a support ticket the Monday after cutover.
Retention behaves the same way
Retention policies and retention labels are the other half of Purview compliance, and they follow the same rule: tenant-scoped, rebuilt in the target, not carried. Your migration tool copies the mailbox and the site content, but the retention policy that was quietly keeping those items for seven years does not travel with them. If you skip this, you can drop content that was under a legal hold or a regulatory retention requirement, and that is the kind of gap that turns a migration into a legal problem. Recreate the retention labels and policies in the target, reapply them to the migrated locations, and confirm that anything under hold in the source is held again before you decommission it.
The honest sequence
Do it in an order that never leaves content exposed. First, inventory the source: every DLP policy, every sensitivity label and its encryption settings, every retention policy and hold. Second, build the matching configuration in the target before any content lands — labels published, DLP recreated in simulation mode so you can watch it without blocking real work, retention in place. Third, deal with encrypted content on its own track, deciding per label whether to decrypt or re-protect. Fourth, migrate the content. Fifth, re-label in the target so classifications carry a native ID, then move DLP out of simulation and turn enforcement on once you have watched it behave. Remember Microsoft's own timing notes here — published labels can take up to 24 hours to reach users, and a DLP policy generally takes effect about an hour after you turn it on. Build that lag into the cutover plan instead of being surprised by it.
The takeaway
There is no native tenant-to-tenant migration for Purview. DLP policies, sensitivity labels, and retention are configuration that belongs to a single tenant, and you recreate them in the target rather than move them. The sharp edges are the label ID that the new tenant has never issued and the encryption bound to the old tenant's rights management — get either wrong and you ship unlabeled or unreadable content. Rebuild the config in the target, re-label after the move, and put the encrypted files on their own track. Do that and cutover weekend stays boring: no sea of unclassified documents on Monday, no users locked out of their own files, nothing left for an auditor to frown at.
Questions people also ask
Can you migrate DLP policies between Microsoft 365 tenants?
Not natively. A DLP policy lives in a central policy store inside one tenant and syncs out to Exchange, SharePoint, OneDrive, Teams, and devices in that tenant. There is no Microsoft feature that lifts a policy into a different tenant. You read the source configuration, then recreate the rules, conditions, locations, and actions by hand in the target Purview portal.
Do sensitivity labels transfer between tenants?
The label definitions do not transfer, and neither does the label stamp on content in a way the target understands. A label is a tenant-specific object with its own identifier stored in each file's metadata. Content moved to the target arrives carrying an ID the new tenant has never issued, so you build matching labels in the target and, where it matters, re-label the content there.
What happens to encrypted files when you move tenants?
Encryption applied by a sensitivity label is tied to the source tenant's rights management. The usage rights name users and groups from the source directory, and the protection is bound to that tenant. Moved as-is, those files can become unreadable in the target because the accounts and keys they trust no longer apply. You plan decryption or re-protection as part of the move, not after it.
Are retention policies part of a tenant migration?
Retention policies and retention labels are Purview compliance configuration, so they behave like DLP: tenant-scoped and rebuilt in the target rather than moved. Your migration tool copies the content, but the retention rules that governed it do not follow. You recreate the retention labels and policies in the target and reapply them, and you confirm nothing under legal hold is dropped.
Do I need a third-party tool to migrate sensitivity labels?
For the label definitions and for re-labeling already-labeled content at scale, yes — Microsoft offers no native path, so tools from vendors like Quest and ShareGate exist to map source labels to target labels and reapply them. For a small estate you can rebuild labels manually and re-label by hand. Either way you first build matching labels in the target.