Tenant-to-Tenant Migration Explained: Identity, SharePoint, Teams, and Cutover

Direct answer: Tenant-to-tenant migration moves mailboxes, SharePoint, Teams, OneDrive, domains, and identity from one Microsoft 365 tenant to another — usually after a merger, acquisition, or divestiture. Run it as a program with identity, messaging, collaboration, and change-management tracks, staged coexistence, and per-workload validation sign-off. The file copy is the easy part.

Start from the migration hub and the assessment checklist. Workload guides: Exchange migration, SharePoint migration, and validation with Python. The quick answer lives at What is tenant-to-tenant migration?

Start with the business decision

Before choosing tools or dates, settle what the combined business should look like: which tenant is the destination, who is authorized to approve the move, which people and business units are in scope, and which must remain separate. Those decisions determine the account, domain, and access plan — no transfer tool can make them for you. A migration is also a rare chance to reset naming standards, remove stale accounts, tighten admin access, and retire duplicate tooling, so agree the cleanup ambition up front rather than discovering it mid-project.

Build a discovery workbook

Answer one question for every workload: what exists today, where it lands tomorrow, and who owns validation. A solid inventory covers users and aliases, shared and resource mailboxes, distribution and security groups, SharePoint sites and OneDrive accounts, Teams with channels and guest access, retention holds and compliance policies, DNS records and domain ownership, Intune-managed devices, licenses on both sides, and every third-party dependency — line-of-business apps, scanners, copiers, SMTP relays, backup and security tools. Hidden dependencies surface late and late surprises are expensive, so treat discovery as a deliverable with sign-off, not a spreadsheet skim.

Phase 1: Identity and domains

Map every source identity to its target: users, groups, guests, service principals, and app registrations. Decide the domain strategy early — domains transfer once, and mail flow, Teams, and SharePoint URLs all feel the sequencing. Establish coexistence mail flow so both tenants deliver during the transition, and freeze identity changes in a change window around cutover.

Phase 2: Messaging

Move mailboxes in batches with coexistence, then cut MX records per the domain plan. Validate mail flow both directions, shared mailboxes, delegates, and transport rules before declaring messaging done — messaging failures are the most visible migration failures. Run a staged rhythm: initial syncs early while users keep working, final delta syncs close to cutover, then the DNS switch. Lower DNS TTL values ahead of the window, confirm mailbox mapping with pilot users, and keep source access available for a short safety window afterward. Shared mailboxes, room mailboxes, transport rules, SMTP relay apps, and multifunction printers each need their own checklist line — they generate most post-cutover tickets when treated as footnotes.

Choose the migration method per workload

There is no single method that fits every tenant. Most programs combine native Microsoft capabilities, third-party platforms, and scripting with a staged coexistence model. Microsoft native cross-tenant mailbox migration keeps data inside the Microsoft cloud; confirm current licensing rules first, since Microsoft has required a Cross Tenant User Data Migration add-on for certain native scenarios and missing licenses stop projects cold.

• Migration Orchestrator: moves Exchange mailboxes, OneDrive content, Teams chats, and Teams meetings together in one batch with dependency-aware sequencing. It moves content, not identities — target accounts must already exist and be mapped. Mailboxes on hold are blocked, OneDrive moves are one-time with no delta passes, and source mailboxes are removed after success, so preservation decisions belong before cutover.
• Individual workload paths: cross-tenant SharePoint and OneDrive moves suit narrow scopes but carry eligibility limits and destination restrictions — verify them against your tenant type before committing.
• Third-party platforms: earn their place with broader SharePoint, Teams, Groups, and permission coverage plus staged waves, flexible scheduling, and consolidated reporting. They carry their own licenses, permissions, and data limits, so compare coverage artifact by artifact.
• Scripting and Graph: PowerShell and Microsoft Graph handle discovery, remediation, reporting, and automation around whatever mover you pick.

Plan licensing early

Subscriptions generally cannot move between tenants under CSP and NCE terms, so the target tenant needs its own subscriptions before waves begin. Budget for an overlap period where both tenants run, confirm service-plan parity so nobody loses archives, Teams Phone, Defender, Purview, or Intune features, and watch NCE term, renewal, and seat-reduction constraints. Assign licenses through groups where possible and decommission source subscriptions only after validation, retention, and legal sign-off.

Phase 3: Collaboration content

Migrate SharePoint sites, Teams (channels, files, and chats within fidelity limits), and OneDrive accounts in dated waves. Remap permissions to target identities, expect Teams chat history and app configuration to migrate imperfectly, and inventory those gaps with stakeholders before dates are promised. Apply the same wave discipline as any migration: pilot, bulk, delta, validate, sign off. Pilot with a complex site — custom permissions, large libraries, active collaboration — because a pilot of only simple sites proves nothing.

Workload	What must stay intact	Common risk	Practical approach
Entra ID	UPNs, aliases, groups, MFA plan	Sign-in failures, wrong membership	Pre-stage users and groups, verify mapping
Exchange Online	Mail, calendar, contacts, shared mailboxes	Domain cutover errors, missed deltas	Staged syncs, final delta, planned DNS switch
SharePoint Online	Files, versions, metadata, permissions	Broken links, orphaned access	Pilot complex sites first, incremental copy
OneDrive	User files, sharing, known folders	Missing ownership, unsynced files	Move after identity prep, verify with users
Teams	Membership, channels, files	Lost chats, missing apps, member confusion	Rebuild deliberately, pair with identity and files work

Give Teams its own plan

Teams is several workloads bundled together: membership depends on Entra ID, channel files live in SharePoint, private chat files sit in OneDrive, and meetings, tabs, apps, and connectors each behave differently. Start with topology — every team, channel, owner, guest, private channel, and app dependency — then decide per team whether to move, archive, or rebuild cleanly. Dormant project teams often should not come forward at all. Set realistic chat expectations in writing, and give users a one-page cutover guide covering when to sign out and back in, where files now appear, and what looks different. That single page prevents a flood of Monday-morning support calls.

Phase 4: Cutover and close

• Transfer domains on the sequenced date; verify Teams, SharePoint sharing links, and Power Platform connections against new URLs.
• Re-consent app registrations and rebind Power Automate connections and Copilot Studio knowledge in the target.
• Run delta passes until unexpected changes hit zero, then decommission source licenses on an explicit date.
• Collect validation evidence per workload — counts, permissions, sharing, owner acceptance — before closing each track.

What to tell stakeholders

Some fidelity loss is normal: chat history, version metadata nuances, and sharing-link remapping should be communicated as known constraints with workarounds, not discovered as surprises. A short, honest constraints list signed off before migration beats a long apology after it.

Do not forget devices, apps, and relays

Intune-managed devices usually need re-enrollment or fresh compliance evaluation in the target — plan enrollment methods, configuration profiles, and app protection policies per wave. Third-party SaaS, CRM, backup, and workflow tools often depend on tenant-specific app registrations, OAuth consent, or SSO, so inventory and re-consent them. Anything that sends mail as the organization — SMTP relays, printers, line-of-business systems — gets tested against the new routing before cutover, not after.

Prepare the end-user experience

A technically clean migration still feels disruptive if users are unprepared. Communicate what changes and when: Outlook profile repairs, mobile mail reconfiguration, OneDrive sync resets, Teams cache clears and re-sign-in, new meeting links, MFA re-registration, and possible Intune re-enrollment. Equip the help desk with scripts and a known-issue guide, extend support coverage across cutover windows, and give executives a named support path — their downtime tolerance is the lowest in the company.

Protect compliance and chain of custody

Design Purview retention, eDiscovery, legal hold, DLP, sensitivity labels, audit logging, and data residency into the plan from the start, not as a post-migration review. Mailboxes on hold block native moves, so resolve hold strategy before batching. Document chain of custody for regulated data, confirm migrated content stays discoverable and protected in the target, and never decommission the source tenant until legal, compliance, and business owners confirm required evidence is preserved.

How long it takes and what drives cost

Small simple tenants can finish quickly; complex or regulated programs run weeks to months. Timeline hinges on user count, data volume, identity model, domain complexity, Teams and SharePoint scope, licensing lead times, compliance gates, and support readiness. Cost follows the same drivers plus method licenses, destination subscriptions, application remediation, and transition support. Any estimate quoted on user count alone is a guess — insist the quote separates discovery, migration labor, tool licenses, subscriptions, remediation, and hypercare.

Run a 30-day hypercare

Cutover day should feel boring; the month after decides whether the migration sticks. Keep a focused support queue, review audit logs, clean up leftover licenses and stale guest access, confirm backup coverage in the new tenant, and verify security baselines match current needs. Close each track only with validation evidence — counts, permissions, sharing, owner acceptance — and a named owner for every remaining issue.

FAQ

Can this be a weekend lift-and-shift? Only for tiny tenants. Anything with Teams history, custom permissions, or integrated apps needs the full program.

What about Power Platform and Copilot assets? Inventory flows, apps, and agents early — connections, knowledge sources, and environment strategy all rebind to the target tenant.

Continue with the migration timeline quick answer and the migration hub.