Tenant-to-Tenant Migration Security: Moving Mailboxes, Sites and Identities Without Opening Trust Holes

A tenant-to-tenant migration creates, for a few months, the most privileged non-human identities either organisation will ever hold: apps and admin accounts that can read and move every mailbox and site in two tenants at once. Mergers, divestitures and consolidations end with users, mailboxes, OneDrive accounts, sites and domains moving between tenants. This guide covers the security layer of that move: migration credentials, trust scoping, holds and eDiscovery, and decommissioning, using Microsoft 365's native cross-tenant features as the worked example, and applies equally when a third-party migration service does the moving. For the wider M&A identity picture (due diligence, day one access, coexistence) read the Identity Integration in M&A Guide first; this page goes deeper on the migration itself.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• The migration app is a privileged NHI. Native mailbox migration uses an app registration with the Mailbox.Migration permission and a client secret; third-party tools usually ask for tenant-wide mail, file and directory access. Treat both as tier 0 for the life of the project and delete them at the end.
• Scope the trust, not just the app. The source tenant controls which mailboxes can leave through a mail-enabled security group named in MailboxMovePublishedScopes; keep that group small, owned and change-controlled.
• Holds and eDiscovery move with the data, or not at all. Mailboxes on hold are blocked, OneDrive holds must be removed and reapplied, and after a mailbox move eDiscovery is only possible in the target. Agree this with legal before the first batch.
• Coexistence is the risky period. Two tenants, redirects, forwarding addresses, synchronised guests and open organisation relationships all exist at once. Time-box it and log it.
• Decommissioning is a security task. Remove endpoints, organisation relationships, SharePoint trusts, apps, secrets, consents and redirects on a dated plan, and prove it with a final inventory of both tenants.

The migration toolset and the access each part needs

A Microsoft 365 tenant move is several features, each with its own trust and credential.

Microsoft notes that cross-tenant synchronisation is not a migration tool, because synchronised users still authenticate through the source tenant. It is useful for coexistence, not for the move itself. See the Entra ID Cross-Tenant Access and B2B Guest Governance Guide for its settings.

Threat model: where a migration opens trust holes

A migration service with tenant-wide grants to two tenants signs in with an application credential as the app itself, with no user and no MFA in the path, so the customer-side controls focus on what is consented, for how long, and how fast it can be cut off.

Securing the migration identities

Native mailbox migration app

• Permissions: Microsoft's procedure registers a multi-tenant app in the target tenant with the Mailbox.Migration application permission under Office 365 Exchange Online. The default User.Read delegated permission is not required for mailbox moves and Microsoft says it can be removed. Remove it.
• Consent: the target administrator grants admin consent, and the source administrator accepts the app through an admin consent URL. Record both consents in the change ticket.
• Secret handling: the documented example builds the migration endpoint credential from a plain-text variable. In production, read the secret from your vault at run time, set a short expiry that covers the project plus contingency, and never paste it into shared scripts. Microsoft notes the secret value is visible only at creation, so store it immediately in the vault and nowhere else.
• Ownership: name an owner in each tenant, inventory the app with an end date, and alert on new credentials. See the How to find high-privilege Microsoft Graph application permissions guide for the review query pattern.

Third-party migration services

• Read the permission list before consent: tools commonly request application permissions such as full mailbox access through Exchange Web Services, Sites.FullControl.All or Files.ReadWrite.All, and directory read. Consent only for the workloads you are moving.
• Prefer Graph and scoped access: the ApplicationImpersonation role in Exchange Online was retired, with Microsoft confirming the deprecation complete in March 2025, and EWS in Exchange Online begins global disablement in October 2026. Ask providers to confirm their Graph-based method. Where the tool uses application mail permissions, Exchange Online RBAC for Applications can scope an app to a management scope or administrative unit; Microsoft is explicit that an unscoped grant in Entra ID combined with a scoped grant in Exchange gives no effective scoping, so remove the tenant-wide grant when you scope. See the Exchange Web Services retirement guide.
• Credentials held by the provider: ask where the provider stores tokens or secrets for your tenants, how they are isolated per customer, and how you are notified of compromise. Put a revocation contact in the contract. See the SaaS and OAuth App Governance Guide.

Human administrators

• Separate accounts: project engineers work from cloud-only admin accounts in each tenant, with phishing-resistant MFA, never from guest accounts in the other tenant.
• Least privilege: only the organisation administrator can change MailboxMoveCapability on an organisation relationship, and the Move Mailboxes role is what runs moves. Grant those, plus SharePoint Administrator for content moves, through just-in-time activation rather than standing Global Administrator.
• Break glass stays separate: do not move emergency access accounts, and keep one Global Administrator on a domain that is not being removed, as Microsoft's domain removal procedure also advises.

Scoping and trust configuration

OneDrive and SharePoint target hygiene: Microsoft requires that target OneDrive accounts and sites are not created before the move, because an existing target cannot be overwritten. Restrict OneDrive creation in the target for migrating users until their move completes.

Data, holds and eDiscovery

Plan retention and legal hold with legal and records management before the first pilot.

• Mailboxes on hold: Microsoft states that mailboxes on any type of hold are not migrated and the move is blocked. Decide per custodian: release the hold, copy content to a mailbox that stays in the source, or exclude the user.
• Source mailbox after the move: after a successful move the source mailbox is not available, discoverable or accessible in the source tenant, and eDiscovery is only possible in the target. If the source organisation has a retention duty (a divestiture with a transition services agreement, for example), copy what it needs before the move.
• OneDrive holds: legal holds block OneDrive migration. Remove the hold, migrate, and reapply the policy in the target. Reconcile the hold register after every wave so nothing is left unprotected.
• Sensitivity labels: labels may not carry their protection across tenants, and labels with user-defined permissions block SharePoint migration. Microsoft recommends removing labels before migration and reapplying them after. Map source labels to target labels in advance, and track every decrypted file so protection is restored.
• What moves and what does not: mailbox migration moves mailbox content, including Recoverable Items. Microsoft 365 Groups, Teams chat, labels and mailbox permissions need separate handling; Teams channels, workflows and Power Automate flows are rebuilt after SharePoint moves. Treat each rebuilt flow as a new integration identity.
• Encryption keys: a source tenant using Microsoft Purview Customer Key service encryption causes OneDrive and SharePoint cross-tenant migration to fail. Plan the key change with your key custodians. See the BYOK, HYOK and External Key Management Guide.

Coexistence and cutover

• Mail routing: after a mailbox moves, a MailUser remains in the source with a target address for routing, and inbound mail passes source-tenant security and compliance first, then the target's. Keep both tenants' mail filtering and transport rules aligned during coexistence, and alert on new forwarding rules in either tenant.
• Redirects: OneDrive and SharePoint moves leave a redirect at the old location until the source tenant is deprovisioned, and shared links redirect only when the recipient still has access in the target. Inventory redirects and remove them deliberately, site by site.
• Domain move: a domain can only be removed when no users, groups, contacts or admin sign-in names use it, and removal can take from minutes to a day. During that window, neither tenant answers for the domain. Lower DNS TTLs in advance, protect the registrar account, and watch for lookalike domains. See the DNS Security Guide.
• Conditional Access in the target: moved users meet the target's policies on first sign-in. Do not weaken policies for migration week. Expect a surge of MFA reset requests, a classic social engineering cover; apply the Account Recovery and Help Desk Security Guide controls.

Implementation approach

1. Inventory both tenants. List admin accounts, apps and service principals with their permissions, cross-tenant access settings, holds, labels, Customer Key status and domains.
2. Write the migration security plan. Name owners for each migration identity, the vault location for each secret, approval steps for scoping group and mapping file changes, the hold decisions per custodian, and the decommissioning date. Our recommendation is a maximum project credential lifetime of 90 days, renewed only with a fresh approval.
3. Build the trust in a pilot. Configure the relationships, trust and app with a pilot group of five to ten volunteers. Run Test-MigrationServerAvailability and Get-MoveRequest -Flags "CrossTenant" to confirm what the endpoint can reach.
4. Test the negative. Attempt to move a mailbox outside the scoping group and confirm it fails with MailboxNotInCrossTenantMigrationScopeException. Confirm an out-of-scope user is not in the identity mapping file.
5. Migrate in waves. One scoping group and one batch per wave, each with a change ticket, legal sign-off for held custodians and a post-wave hold and label reconciliation.
6. Roll back safely. OneDrive and SharePoint moves are one-time and cannot merge into existing targets, so content rollback is a restore plan: confirm backups of both tenants before each wave. See the Microsoft 365 Backup.
7. Decommission. Remove migration endpoints (Remove-MigrationEndpoint), organisation relationships (Remove-OrganizationRelationship), SharePoint trusts, the migration app registration and its secrets, third-party service principals and their consents, sync configurations and inbound cross-tenant settings. Microsoft's procedure names the first two; schedule the rest yourself.
8. Prove it. Re-run the inventory from step 1 in both tenants and file the difference as evidence.

Decision guidance

Detection and measurement

Retain audit logs from both tenants in one SIEM workspace from before the first change. Watch for:

• App changes: "Consent to application", "Add app role assignment to service principal" and "Add service principal credentials" on the migration app or any app in either tenant during the project. See the Microsoft 365 Unified Audit Log Guide for Detection.
• Trust and sign-in anomalies: organisation relationship or cross-tenant setting changes outside change windows, and migration app sign-ins after the project end date.
• Scope changes: membership changes to the scoping group, especially additions of executives, shared mailboxes or held custodians.

Common failure patterns

• The forgotten migration app: the project closes, but the app and its secret remain, consented in a tenant that now belongs to another company.
• Scoping by "all users": a scoping group built from a dynamic rule that later includes people who should never have moved.
• Holds released to unblock a batch: the hold is never reapplied, and a later legal request finds nothing.
• Coexistence with no end: sync and inbound access settings stay on years after a divestiture.
• Third-party tool left consented: the migration service keeps tenant-wide mail and file access with credentials stored outside your control.

Framework mapping

Practitioner checklist

• Baseline both tenants: admins, apps, permissions, cross-tenant settings, holds, labels, domains.
• Register the native migration app with only Mailbox.Migration, remove User.Read, and keep its secret in a vault with an end date.
• Review every permission a third-party migration service requests and consent only for workloads in scope.
• Set organisation relationships with tenant IDs and a small, owned scoping group per wave.
• Agree hold, eDiscovery and label decisions with legal before the pilot, and reconcile after every wave.
• Use just-in-time admin roles; keep break glass accounts and one Global Administrator off the domain being moved.
• Remove endpoints, relationships, trusts, apps, secrets, consents and redirects on a dated plan.

Standards and references

• Microsoft Learn: Cross-tenant mailbox migration
• Microsoft Learn: Cross-tenant OneDrive migration
• Microsoft Learn: Cross-tenant SharePoint migration
• Microsoft Learn: What is cross-tenant synchronization?
• Microsoft Learn: Role Based Access Control for Applications in Exchange Online
• Microsoft Learn: Remove a domain
• Microsoft Exchange Team: ApplicationImpersonation RBAC role deprecation in Exchange Online
• MITRE ATT&CK: T1199 Trusted Relationship

Related NHI Mgmt Group resources: Identity Integration in M&A Guide · Cyber Due Diligence in Mergers and Acquisitions Guide · Entra ID Cross-Tenant Access and B2B Guest Governance Guide · SaaS and OAuth App Governance Guide