11 min readPurview Compliance Gaps in M365 Tenant Migrations: The eDiscovery, Retention, and DLP Risks MSPs Can’t Ignore 

When you run a Microsoft 365 tenant-to-tenant migration, success is usually judged by what people can see. 

Users log in. Email delivers. OneDrive syncs. Teams opens without drama. 

On the surface, everything looks clean and complete. 

But beneath that visible layer sits something most people don’t check right away: Microsoft Purview compliance. 

That’s often where real challenges begin. 

Soon after the cutover, the questions start arriving. 

• “Our eDiscovery cases aren’t here. Did they get lost?” 

•  “Why did our retention labels disappear?” 

• “How did that sensitive file get shared? Wasn’t DLP supposed to block it?” 

Suddenly, you’re expected to explain something that was never designed to move. 
Purview compliance objects do not migrate between Microsoft 365 tenants. 
Your data moves, but the compliance framework behind it stays in the source tenant. 

This guide is written for the person responsible for making sure the migration isn’t just successful, but safe, predictable, and compliant. 

What Doesn’t Transfer in a Purview Tenant Migration 

      You can move workloads, but not the compliance brain behind them. 

Once you move past the visible parts of the tenant to tenant migration, you hit the area that behaves differently: Purview. Unlike mail, files, or Teams workloads, Purview isn’t something you can simply lift and shift. 

In a  M365 tenant migration, several key Purview components stay anchored in the source environment, including: 

• eDiscovery cases and holds 

• Retention labels and retention policies 

• Regulatory record labels 

• DLP policies and rules 

These items don’t transfer. There’s no partial carryover and no behind‑the‑scenes sync. They remain where they were created. 

 What makes this tricky isn’t the technology. It’s the assumption gap. The teams who rely on these controls expect them to keep working the same way after Microsoft 365 tenant migration. 

When they don’t, the questions come straight to you. That’s when the pressure starts: surprise meetings, urgent follow‑ups, and the uncomfortable feeling of being accountable for something that was never portable. 

Purview can’t be handled as a side note. It needs its own conversation, its own planning, timeline, and preparation  just like identity, mail flow, and DNS. 

Why Microsoft Purview Objects Don’t Move Between Tenants 

When you move the data, it’s natural to expect Purview to travel with it. It doesn’t. 

Once you look at how Purview is designed, the behavior becomes clearer. Compliance controls were built to stay tied to the tenant where they were created. 

Purview objects depend on several things that only exist inside the original tenant. 

• Tenant specific identifiers and internal IDs. 

• Directory groups and permissions. 

• Content references tied to that environment. 

• Custom classifiers and sensitive information types. 

• Case containers inside a fixed compliance boundary. 

Even if you export configuration details, you still can’t import them into another tenant as functional, working objects. 

 So the question “How do we migrate Purview?” leads you down a dead end. There’s no native path that takes what you’ve built and simply reattaches it in the new tenant. 

The better planning question is different: 
 
“How do we rebuild Purview before anyone needs it?” 

That shift matters because it changes your timeline. Instead of reacting after cutover, you design and rebuild controls before users and stakeholders start testing the new environment. 
One place where this architecture becomes painfully visible is eDiscovery. 

eDiscovery After Tenant Migration: Why Cases Seem to Vanish 

Legal teams expect continuity. After migration, their cases appear to be missing. 

This issue usually isn’t noticed during migration itself. It appears when someone tries to open a case in the new tenant and finds nothing there. 

To legal, HR, and compliance teams, cases feel like data. If users and mailboxes moved, it’s reasonable to assume cases moved too. 

But eDiscovery cases are tenant-bound. Holds, searches, review sets, and permissions are tied to tenant identifiers and compliance boundaries that do not transfer. 

In M&A and litigation‑driven migrations, this problem appears frequently because discovery work must continue without interruption. After cutover, discovery searches against migrated mailboxes no longer behave as expected because the original case objects remain in the source tenant. 

There is also no native Microsoft mechanism that transfers eDiscovery cases between tenants. 

That’s why the issue often appears at the worst possible moment  when someone urgently needs an existing case. 

When cases aren’t where people expect them, the migration feels broken even if everything else worked perfectly. 

 The safest approach has three parts: 

1. Export what matters before cutover. 
   Export searches, results, and key case artifacts so you can reference them later if needed. 

2. Recreate required cases in the destination tenant. 
   Rebuild the structure: scopes, custodians, permissions, and any ongoing holds that need to continue. 

3. Keep the source tenant available in controlled read‑only mode until legal obligations are complete. 
   This one step prevents the nightmare call: “We shut down the old tenant, and now legal needs that case.” 

Retention Labels and Policies: The Quiet Compliance Drop 

Retention problems rarely make noise. 

Unlike DLP incidents, retention gaps usually appear slowly through everyday behavior. 

Instead, the gap shows up through normal day‑to‑day actions: 

• A file that used to be protected gets deleted. 

• A record becomes editable. 

• A label that used to be available is missing. 

No warning. Just changed outcomes. 

Retention isn’t just administrative housekeeping. It supports regulatory preservation and legal defensibility by controlling what content can be deleted and when. 

In Exchange, the risk is particularly serious. If retention policies are not rebuilt quickly in the destination tenant, email retention coverage may disappear temporarily after migration, creating a real compliance exposure window. 

If regulatory record labels were used in the source tenant, remember they cannot be updated by design. they also cannot be ported as working controls into the new tenant. Continuity has to be planned, not assumed. 

 If labels and policies aren’t rebuilt early, the organization can operate with no idea anything is wrong with looser controls than intended. By the time anyone notices, content may already have been deleted or altered. 

 Rebuilding retention isn’t complicated, but it must be deliberate: 

• Recreate labels with the same (or improved) logic. 

• Publish them to the right locations and workloads. 

• Reapply retention and auto‑apply policies. 

• Test outcomes on sample mailboxes, sites, and libraries. 

Treat retention rebuild as a cutover dependency, not a cleanup task. Once users can delete content, you can’t undo the outcome later. 

Microsoft 365 Migration Surprise: Missing or Broken DLP Policies 

DLP doesn’t just go missing quietly it fails in public. 

Retention gaps are usually quiet. DLP gaps are loud. You don’t have to go looking for them; they show up as incidents. 

For example: 

• Sensitive emails get sent without warnings. 

• External sharing happens when it should have been blocked. 

• Alerts that used to appear suddenly stop. 

Because DLP is a visible control, incidents escalate quickly. The explanation becomes simple from a business perspective: 

Sensitive data slipped through. 

At that point, nobody wants to hear about tenant‑bound policies or missing M365 tenant migration features. From the business perspective, controls they trusted “failed” right after the migration you led. 

That’s why rebuilding DLP cannot be postponed until after cutover cleanup. It needs to be rebuilt before activity ramps up in the destination tenant. 

If you have a clear inventory of: 

• Existing DLP policies and rules 

• Exceptions and exclusions 

• Sensitive information types and classifiers 

…the rebuild process is usually straightforward. 

One important fact: there is no native tenant‑to‑tenant migration path for retention or DLP policies. You can document the policy definitions, but they still need to be recreated in the destination tenant. 

Some migration approaches may support moving standard sensitivity labels in certain scenarios. However, that support does not apply to: 

• Retention labels 

• Retention policies 

• Microsoft Purview DLP configurations 

Rebuilding DLP early helps prevent high‑visibility incidents and protects confidence in the migration. 

How to Prevent Purview Gaps During a Microsoft 365 Migration 

The gaps are predictable. The risk comes from ignoring them. 

By now, the pattern is clear. The gaps are predictable, which means they’re controllable. The goal isn’t perfection, it’s control. You want predictable outcomes, clear evidence, and no surprises after cutover. 

1. Start with inventory and export 

Before tenant to tenant migration, build your safety net: 

• Capture retention labels and policies. 

• Export DLP rules, actions, and exceptions. 

• Inventory custom sensitive information types and classifiers. 

• Document auto‑apply configurations. 

• Record every active eDiscovery case and hold. 

If someone later challenges what existed in the old tenant, you can answer with evidence, not memory. 

2. Rebuild in the right order 

Purview has dependencies, so order matters. A practical sequence: 

1. Recreate retention labels. 

2. Rebuild and publish retention policies. 

3. Recreate sensitive information types and classifiers. 

4. Rebuild DLP rules and actions. 

5. Restore auto‑apply logic and label publishing. 

This order ensures DLP and labeling can reference the right building blocks. 

3. Validate before cutover 

Test like someone will audit it: 

• Confirm retention behavior on sample content. 

• Check label availability in Office apps and key locations. 

• Run controlled DLP tests with known sensitive content. 

• Verify auto‑apply triggers, alerts, and incident logs. 

Validation reduces escalations later because you already have proof of how the new tenant behaves. 

4. Define the compliance gap window and close it fast 

Every migration has a period where data exists in the new tenant while compliance controls are still being finalized. 

Ignoring that window creates risk. Acknowledging it builds trust. Documenting it protects you when questions come later. 

Communicate clearly: 

• When the gap will happen. 

• What risks exist during that window. 

• How long it will last. 

• What’s being done to minimize it. 

That one step alone prevents a lot of “Why didn’t anyone tell us?” moments. 

Before migration 

• Export Purview configuration for: 

• Retention labels and policies 

• DLP policies and rules 

• Sensitive information types and classifiers 

• Document all eDiscovery cases and holds. 

• Identify custom dependencies (classifiers, SITs, regulatory records). 

• Plan controlled read‑only access to the source tenant for legal and audit use. 

Before cutover 

• Rebuild retention labels and policies in the destination tenant. 

• Recreate DLP policies, rules, and exceptions. 

• Publish and verify label availability across workloads. 

• Test enforcement of retention and DLP with sample content. 

• Recreate required eDiscovery cases and holds where continuity is needed. 

After migration 

• Maintain controlled access to the source tenant where legal obligations remain. 

• Monitor for DLP incidents and retention behavior in the new tenant. 

• Keep configuration and evidence ready for audits and legal requests. 

The Real Compliance Takeaway in Tenant Migration 

A Microsoft 365 tenant‑to‑tenant migration can look flawless until someone discovers the compliance controls, they rely on never made the journey. 

But when you: 

• Plan for eDiscovery continuity, 

• Rebuild retention and DLP intentionally, 

• Validate behavior before cutover, and 

• Clearly communicate the compliance gap window, 

…the risk stops being invisible. 

The result is a migration that isn’t just technically successful, but compliance‑safe, defensible, and built to hold up under scrutiny. 

Would you like a short, visual checklist or diagram version of this that your team can use in migration runbooks and client presentations?