Tenant-to-Tenant Migration: Office 365 to Office 365

Office 365 to Office 365 is the migration that looks easiest and is actually the most politically complex. The technology is straightforward — Microsoft's native cross-tenant mailbox migration moves mail, calendar, contacts, tasks, and rules in one operation. What's hard is everything around it: UPN suffix planning when two companies share an @example.com, free/busy coexistence during the window where both tenants are live, decisions about Teams chat history that doesn't transfer, and the legal sign-off chain on which user data moves to which entity. This guide focuses on the operational mechanics; the business sequencing belongs in your M&A or divestiture plan.

What you need before you start#

Cross-tenant migration touches identity, DNS, licensing, and Exchange in both tenants simultaneously. Skipping any prep step makes the migration unrecoverable mid-run.

On the source tenant side you need:

• Global admin rights, or at minimum Exchange admin plus Application admin in Entra ID.
• An inventory of every mailbox, shared mailbox, distribution list, Microsoft 365 group, and resource mailbox in scope. Run Get-Mailbox -ResultSize Unlimited plus Get-UnifiedGroup and Get-DistributionGroup and store the output for reference.
• Confirmation of which domains in the source will move. A source tenant typically has multiple verified domains; only some go to the target.
• License inventory — what each user has, which need to keep their license tier post-cutover.

On the target tenant side you need:

• Global admin rights, and the willingness to verify a new domain.
• Sufficient licenses to cover incoming users. Provision before the migration; the cross-tenant flow needs MailUser objects that become full mailboxes once data lands.
• Exchange Online active and configured.
• A clear UPN strategy — do incoming users keep @source-domain.com, take @target-domain.com, or get a third namespace?

On the trust and security side you need:

• An organisation relationship between the two tenants in Exchange Online.
• A cross-tenant Microsoft 365 group consent agreement granting the target tenant permission to read mailboxes in the source.
• Conditional access policies on both sides reviewed for impact. Many tenants have policies that block cross-tenant access by default.
• A communications agreement between the two organisations' security teams so neither side panics at the cross-tenant sign-ins during cutover.

On the planning side you need:

• A runbook signed off by both organisations' IT, security, and legal teams.
• A defined window for free/busy coexistence — typically 7–14 days where both tenants are live and exchanging calendar availability.
• A decision on Teams chat history. It does not move cross-tenant. Either accept the loss or use a third-party tool to export and import as static archives.

The migration in eight steps#

1. Define the cross-tenant scope and namespace plan

   Sit down with the merger or divestiture lead and document exactly which domains move, which UPNs change, and what email addresses users have on day one. The decision tree usually goes: are we keeping the acquired brand (@acquired.com stays primary) or absorbing it (@parent.com becomes primary, @acquired.com becomes an alias)? Get this in writing. The merger and acquisition email migration guide covers the namespace decision in detail. For a spin-off, the divestiture email migration playbook handles the reverse case.

2. Enable cross-tenant trust between source and target

   In both tenants, configure an Organisation Relationship in Exchange Online (New-OrganizationRelationship) pointing at the other tenant. Then set up the Cross-Tenant Identity Mapping in the target tenant, which uses Microsoft Graph to know which source user maps to which target user. Both tenants need to consent to the cross-tenant migration application — this is a one-time admin consent flow per tenant. Without these trusts, the migration endpoint won't authenticate.

3. Prepare the target tenant

   Add the source domain (or domains) to the target tenant. You can't verify it until you remove it from the source, but you can pre-stage the DNS records. For each incoming user, create a MailUser object in the target tenant with the source primary SMTP as the external address. These MailUsers will become full mailboxes when the migration completes. License them ahead of time so there's no provisioning lag during cutover.

4. Configure cross-tenant mailbox migration

   In the target tenant's Exchange admin center, Migration, Endpoints, Add a migration endpoint, and choose Cross-tenant as the type. Point it at the source tenant's primary domain. The connection test will fail if the organisation relationship and consent steps haven't been completed — that's the moment to verify them. Once the endpoint is created, you can run mailbox migration batches against it just like any other migration type.

5. Run a pilot batch of 5–10 users

   Pick pilot users from across the source business — one heavy executive mailbox, one shared mailbox, one user with complex Outlook rules, one in a regulated function with retention or hold settings, one on Mac with Apple Mail. Run them through the migration end-to-end. Validate: calendar items came across with attendees intact, recurring meetings have the right series, Outlook rules apply correctly in the target tenant, mobile devices re-provision via Autodiscover. Let the pilot soak for at least 72 hours before approving bulk.

6. Coordinate the bulk migration and DNS cutover

   Bulk migration runs in batches. Microsoft's cross-tenant tool handles per-batch sizing internally; a typical batch is 100–500 mailboxes depending on size. Run during a Friday-evening to Monday-morning window for medium-sized scopes. Update MX records to point at the target tenant's mail flow. Update Autodiscover CNAME to point at the target's autodiscover.outlook.com. Coordinate with both tenants' security teams so they're aware of the cross-tenant traffic spike.

7. Migrate calendars, contacts, and rules in coexistence

   The native cross-tenant flow moves calendar items and rules with the mailbox, but free/busy lookups during coexistence (where some users are on each tenant) need explicit configuration. Set up Cross-tenant free/busy via organisation relationship configuration on both sides. For Teams chat history, you have two choices: accept that it doesn't move, or use a third-party export tool to create a read-only archive. Distribution lists need to be re-created as Microsoft 365 groups in the target tenant — they don't migrate automatically. Confirm with the broader tenant-to-tenant migration guide.

8. Decommission the source tenant

   After the bulk migration completes, convert source mailboxes to MailUsers in the source tenant pointing at the target. This means mail still flowing to the old address (auto-replies, legacy systems) gets forwarded. Keep this state for at least 30 days. After 90 days with no missed mail, plan the source tenant decommission. If the source tenant has Teams, SharePoint, or OneDrive data still needed, decommission Exchange first and the other workloads separately. The domain change email migration article covers the post-cutover identity work in more depth.

Provider-specific gotchas#

Cross-tenant moves have a different gotcha profile than provider-to-provider migrations. The protocol works; identity and coexistence are where things break.

UPN suffix changes are not transparent. When a user moves from user@acquired.com to user@parent.com, every system that uses their UPN as an identity key — Single Sign-On, SCIM provisioning, third-party SaaS — needs reconfiguration. Plan a SaaS audit before you start. Slack, Salesforce, ServiceNow, Workday, and any homegrown app that uses UPN-based auth will need to be updated within the same change window.

Free/busy breaks for the duration of coexistence. During the period where some users are on the source tenant and some are on the target, calendar free/busy lookups across the tenant boundary require explicit organisation relationship configuration. Without it, users on the target see "no information" when trying to schedule meetings with users still on the source. The fix is fast (a single PowerShell command on each side) but easy to forget until users complain.

Distribution lists do not migrate. Native cross-tenant migration moves user mailboxes and shared mailboxes, but distribution lists and mail-enabled security groups stay in the source tenant. Re-create them as Microsoft 365 groups in the target tenant before cutover, and set up forwarding from the source distribution lists to the new target groups for the coexistence period.

Teams chat history does not move. This catches every M&A migration. Teams chat history is tied to the source tenant identity and doesn't follow the user to the target. SharePoint sites and OneDrive files have separate migration paths (Microsoft 365 Migration Manager or third-party tools). Communicate the chat loss explicitly — users will assume it transferred unless told otherwise.

Conditional access policies bite during cutover. If either tenant has conditional access policies that block sign-ins from unusual locations, the cross-tenant migration sign-ins can trigger them. The migration appears as a cross-tenant guest principal accessing user mailboxes. Pre-configure a conditional access exception for the migration service principal in both tenants.

Litigation hold metadata moves; chain of custody narratives do not. The hold status on a mailbox can transfer with cross-tenant migration, but if you're moving for legal reasons (carve-out, divestiture), legal will want a documented chain of custody. The technical migration doesn't produce one — that's a manual artefact you have to build during the run.

Common errors#

The errors specific to cross-tenant migration, separate from general Exchange Online errors:

• The migration endpoint could not connect to the source tenant — Organisation relationship or cross-tenant consent missing. Verify with Get-OrganizationRelationship on both sides and re-grant admin consent for the migration application.
• TargetUserAlreadyHasMailbox — You created a full user mailbox in the target instead of a MailUser. Cross-tenant migration requires a placeholder MailUser, not a real mailbox. Convert with Set-User -Identity <user> -ToMailUser or recreate.
• AccessDenied: cross-tenant — Conditional access policy in source or target tenant is blocking the migration service principal. Add the migration app to the conditional access exclusion list temporarily.
• OAuth2 token expired — Same as standard Office 365 migrations. Refresh the migration tool's authentication and resume.
• SourceMailboxNotFound — The source mailbox was deleted, soft-deleted, or never existed. Check Get-Mailbox -IncludeInactiveMailbox on the source.
• UserPrincipalNameConflict — The UPN you're trying to assign in the target tenant already exists. Common when both tenants had users with the same first.last combination. Plan UPN collisions before migration.
• Too many simultaneous connections — Even cross-tenant migrations are subject to Microsoft's throttling. Reduce the batch concurrency setting and resume.

Communicating with your users#

Tenant-to-tenant migrations need communications calibrated to the business reason: an M&A migration is also a brand and identity message, a divestiture is a separation message, a re-architecture is an internal-IT message. The plumbing of the comms is similar; the tone differs.

For M&A migrations, lead with the business context. Users at the acquired company want to know: am I still here, what's my new title, what's my new email, do I still report to the same person. Email is the visible artefact of the merger so users read it as a signal. Get HR's sign-off on every comm.

For divestiture migrations, the comms are about separation: a clean line between past and future. Users moving to the spun-off entity want clarity on what data goes with them (their mail does, their Teams chat doesn't) and what stays (corporate IP, customer lists are subject to legal review). The divestiture email migration guide has a comms template specific to this scenario.

For pure IT re-architectures (tenant consolidation, region moves), keep it operational. Date, what changes, what doesn't, how to reach support. Users in this scenario don't want a story; they want a checklist.

Across all three scenarios, the same migration-day pattern applies: a 72-hour heads-up, a 24-hour reminder, a "starting" message at the start of the window, a "complete" message when it's done. The complete email migration guide has the reusable cadence.

Post-cutover, watch for two specific issues: users who can't sign in (usually a UPN cache problem on their device — sign-out, restart, sign-in fixes 90%), and users complaining about missing calendar items (almost always a free/busy coexistence issue rather than actual data loss). Address both with prepared FAQ entries linked from your support channel.