Architecture
What breaks security during a tenant-to-tenant migration
Mergers move mailboxes and forget policy. The controls that silently do not come with you, and the window where nobody owns security.
Microsoft
Migrations are scoped as data projects
Mailboxes, OneDrive, SharePoint sites, Teams. The plan, the budget and the tooling are all built around moving content, and content is the part that moves reliably.
Security configuration does not move. Conditional Access policies, compliance policies, DLP rules, sensitivity labels, PIM assignments and Defender configuration are all recreated by hand in the destination, or quietly not recreated at all.
| Moves with the tooling | |
|---|---|
| Mailbox content | |
| OneDrive and SharePoint files | |
| Teams chat history | |
| Conditional Access policies | |
| Intune compliance and configuration | |
| Sensitivity labels and their protection | |
| DLP policies | |
| PIM role assignments |
Some third-party tooling covers more of the policy layer. Verify claims against your own configuration rather than the datasheet.
The window nobody owns
Between cutover and the destination policies being fully enforced, users exist in a tenant with weaker controls than the one they left. That window is frequently weeks, it is rarely on anybody's risk register, and it is exactly when an acquiring organisation is a known, newsworthy target.
Name an owner for that window before cutover. It is the single most useful thing security can contribute to a migration plan.
What to do about it
Export the source policy set before anything moves
Conditional Access, compliance policies, DLP, labels. You need the source of truth for what protection existed, because after cutover nobody will be able to reconstruct it.
Build the destination policies before the first mailbox
In report-only mode, targeting the groups migrated users will land in. Enforcement then follows the users rather than trailing them.
Migrate privileged users last
They have the most access and the fewest people watching. Moving them first is common and backwards.
Re-run the label and DLP work as a project, not a task
Sensitivity labels do not survive the move intact. Budget for it explicitly, because it will otherwise be discovered by the first person who opens a protected document and cannot.
The verdict
Treat destination policy as a prerequisite, not a follow-up
It is the only approach where users are never less protected after the move than before it, and it costs nothing extra if planned at the start.
Do not accept a migration plan with no named owner for the security configuration. That gap is where the risk in these projects actually sits.
Disclosure. Some links on this site are affiliate links. Scoring weights are published before any programme is joined, and commission is never a ranking input. Full policy, and the method behind this guide.