Office 365 (Microsoft 365) Tenant to Tenant Migration: The Complete 2026 Guide

• 19 October 2026
• Microsoft 365
• Written by Editorial Team

Every tenant to tenant migration starts with a business event. A merger closes, a division is sold, two brands become one, or a company finally leaves a tenant it never really controlled. The technical job that follows sounds simple: move mailboxes, files and teams from one Microsoft 365 environment to another. In practice it is one of the most dependency-heavy projects an IT team will run.

This guide explains how an Office 365 (now Microsoft 365) tenant to tenant migration works in 2026, what Microsoft’s own tools can and cannot move, how the main third-party platforms compare, and how to sequence the work so cutover day is uneventful. It also covers timelines, cost, common failures and a post-migration checklist.

A quick note on naming: Microsoft rebranded Office 365 as Microsoft 365, but admins and search engines still use both terms for the same thing. We use them interchangeably here.

In this guide:

• What is a tenant to tenant migration?
• What can you migrate between tenants?
• Choosing a migration approach
• What Microsoft’s native tools cover
• Third-party tools compared
• Native vs third-party: how to decide
• Example scenarios
• Step-by-step migration plan
• Security, communication and rollback
• How long it takes
• What it costs
• Common challenges and troubleshooting
• Post-migration checklist
• When a managed migration makes sense
• FAQs

What Is an Office 365 Tenant to Tenant Migration?

An Office 365 tenant to tenant migration moves users, mailboxes, files and collaboration data from one Microsoft 365 tenant to another, usually after a merger, acquisition, divestiture or rebrand.

A tenant is your organization’s dedicated instance of Microsoft 365. It holds your users, domains, licenses, policies and data. Two tenants are separate security and administrative boundaries. They do not share identities, storage or settings, which is why you cannot simply drag a mailbox or a SharePoint site from one to the other. Something has to copy or move the content, and something has to make sure the right person lands on the right data on the other side.

The reasons organizations do this tend to fall into five groups:

• Mergers and acquisitions, where two companies need to share one environment.
• Divestitures and carve-outs, where a business unit leaves with its own users and data.
• Rebrands, where a new domain and a clean tenant are easier than renaming an old one.
• Consolidation of several tenants created by past projects, regions or business units.
• Moving off a reseller-hosted or syndicated tenant onto a direct tenant the organization actually controls.

We see that last scenario more often than people expect. A California non-profit had bought its Microsoft 365 subscription bundled with its web hosting service, and the host’s customizations blocked basic admin tasks such as adding Project Online. Apps4Rent moved the non-profit off its hosting provider’s tenant and onto a direct tenant, with the core migration finished in a few hours.

It also helps to say what this topic is not. It is not a license transfer between Microsoft partners, and it is not the same as moving Azure subscriptions between Entra tenants, which is a different procedure with different tooling. This guide is about Microsoft 365 workloads: Exchange Online, OneDrive, SharePoint, Teams and the identities and domains that sit around them.

What Can You Migrate Between Microsoft 365 Tenants?

You can migrate mailboxes, OneDrive accounts, SharePoint sites and, with the right tools, Teams data between tenants, but each workload has its own rules and none of them moves on its own.

Scope is where projects quietly go wrong. Teams think “migrate the tenant” and discover three weeks in that shared spaces, devices and automations were never part of the plan. This table shows what typically moves and what to plan for.

Workload	What moves	What to plan for
Exchange Online mailboxes	Email, calendar items, contacts, tasks and notes	Holds block the move. Delegates and shared access must move together. Mailboxes near quota can fail.
OneDrive	Files and folders, with a redirect left at the source	The move is one and done, with no incremental passes. Long file paths and existing target OneDrives cause failures.
SharePoint sites	Sites, libraries and permissions for users you have mapped	Target sites must not already exist. Workflows, apps and some web parts need rebuilding.
Teams chats and meetings	Chat history and meeting content, through the Orchestrator or third-party tools	Source copies remain, duplicate threads are possible and meeting links may need recreating.
Teams and channels	Not moved by Microsoft’s user data tools	Use a third-party platform or rebuild teams in the target tenant.
Microsoft 365 Groups and Planner	Not covered by Microsoft’s cross-tenant mailbox migration	Check third-party coverage or plan a rebuild.
Power Platform	Apps and flows can be recreated	Connections to data sources must be re-established in the target tenant.
Devices and Intune	Enrollment and policies are tenant-specific	Plan to re-enroll devices and reapply policies.
Domains and DNS	Moved rather than copied	The domain is released from the source tenant, verified in the target and mail flow is switched.

The pattern is worth remembering. Microsoft’s native tooling is strongest on personal data (mailbox, OneDrive, chats) and weakest on shared collaboration spaces. That gap is exactly where third-party platforms and careful project planning earn their place.

Which Migration Approach Should You Choose?

Choose a single event migration for small, simple environments, a phased migration for larger or business-critical ones, and a tenant move or split when only part of the organization is changing tenants.

Microsoft’s own architecture guidance describes these three models, and they map neatly onto real situations. You can read Microsoft’s reference material on its tenant to tenant migration architecture page.

Single event migration

Everyone and everything moves in one planned cutover. It is the simplest to communicate and the quickest to finish, but it concentrates risk into one window. It suits smaller organizations with limited shared content and a clear weekend or evening to work with.

Phased migration

Users move in batches over days or weeks while both tenants stay live. This spreads risk and gives support teams a manageable queue, but it creates a period where colleagues sit in different tenants. Mail routing, calendar visibility and the address book have to keep working across that gap. Microsoft’s standalone mailbox migration leaves a mail user in the source tenant that forwards mail to the new mailbox, which behaves much like Exchange hybrid routing. Several third-party platforms also advertise their own coexistence features, such as mail flow and free/busy sharing between tenants.

Tenant move or split

A defined group of users moves to a new tenant while the rest stay behind. This is the divestiture pattern. It needs the most careful scoping because shared content, groups and distribution lists often straddle the boundary between who leaves and who stays.

When you are deciding between them, these questions settle most debates:

• How many users and how much data are involved, and how large should each wave be?
• How much downtime or confusion can the business tolerate?
• How much of the value sits in shared content such as SharePoint sites and Teams channels?
• Is there a hard deadline, such as a legal close date or an expiring contract?
• How much migration experience does your in-house IT team have?

What Microsoft’s Native Tools Cover in 2026

Microsoft now offers three native paths: the Migration Orchestrator for user data, standalone cross-tenant mailbox migration, and cross-tenant OneDrive and SharePoint migration, and together they still leave Teams and channels uncovered.

Many older guides describe Microsoft’s tooling as mailbox-only or missing entirely. That is out of date. The picture in 2026 is more capable, but it comes with conditions that matter when you plan.

The Migration Orchestrator

The Migration Orchestrator coordinates four workloads in a single batch: Exchange mailboxes, OneDrive accounts, Teams chats and Teams meetings. It runs a validation stage before data moves and sequences the workloads in an order that respects their dependencies, which removes a lot of manual choreography.

Read the fine print before you build a plan around it:

• It moves content, not identities. You create and configure the target users yourself, and identity mapping between source and target is mandatory.
• Mailboxes on any type of hold are not migrated. Microsoft blocks those moves.
• The source mailbox is deleted after a successful move. The source user is converted to a mail user that routes mail to the target.
• OneDrive moves are one and done. Incremental and delta passes are not available.
• Teams chats are copied, not relocated. The original content remains in the source tenant, possibly in edited form, and duplicate threads can appear on both sides. Users need Teams licenses in both tenants.
• Shared data stays behind. Teams and channels and SharePoint sites are explicitly out of scope.

At the time of writing, Microsoft’s documentation still refers to the Orchestrator as a preview. Confirm its current status on Microsoft Learn before you commit a production project to it.

Standalone cross-tenant mailbox migration

Cross-tenant mailbox migration is the generally available option, run through Exchange Online PowerShell. Setup is hands-on. You register a multi-tenant application in Microsoft Entra, create a migration endpoint and an organization relationship, and scope the move with a mail-enabled security group in the source tenant.

The details that trip people up are on the target side. Each user must exist in the target tenant as a mail user carrying the source mailbox’s ExchangeGUID, its ArchiveGUID if an archive exists, and the source LegacyExchangeDN stamped as an x500 address. That x500 address is what lets people reply to old messages after the move. Microsoft’s documentation also lists several limits worth knowing up front:

• Teams meeting links are not updated during a mailbox move, so organizers must recreate those meetings.
• Cross-tenant mailbox and calendar permissions are not supported. Move delegates and the people they support in the same batch.
• Microsoft 365 Groups are not supported by this feature.
• Cross-cloud moves, such as Worldwide to a government cloud, are not supported.

Cross-tenant OneDrive and SharePoint migration

Both run through SharePoint Online PowerShell. For OneDrive, each account can hold up to 5 TB or one million items, full paths cannot exceed 400 characters, and accounts on hold are blocked until the hold is removed. Microsoft’s OneDrive guidance also states that the feature is not supported for the government clouds (GCC, GCC High and DoD).

SharePoint has stricter conditions. Cross-tenant SharePoint migration requires that target sites do not already exist, that source sites are in read/write mode, and that sites stay within 5 TB and one million items. Sites that use sensitivity labels with user-defined permissions cannot migrate this way, and workflows, apps and Power Platform connections have to be recreated afterward. Up to 4,000 OneDrive and SharePoint accounts can be queued at once, and that limit is shared between the two.

Licensing in plain terms

Microsoft requires a Cross-Tenant User Data Migration license for each person whose mailbox or OneDrive moves. It is a per-user, one-time fee that can be assigned to either the source or the target user, and migrations fail without it. Microsoft’s Orchestrator documentation says it is available for Enterprise Agreement, CSP, web direct, small business and education customers. SharePoint site moves use a separate Cross-Tenant Shared Data Migration license, sold per 100 GB of data moved with a 20 percent grace allowance, and currently offered to Enterprise Agreement customers only. If you buy through a Cloud Solution Provider, your provider can confirm the exact SKU and price for your agreement.

What this means for your plan

For many projects the practical shape in 2026 is a split: Microsoft’s native path for personal data (mailboxes, OneDrive and chats) and a different answer for shared content. If you are not an Enterprise Agreement customer, the native SharePoint path is not currently open to you, so plan on a third-party platform or a rebuild for sites. If Teams and channels matter to the business, the same applies. Deciding this early keeps you from discovering a gap halfway through the project.

Third-Party Migration Tools Compared

BitTitan MigrationWiz, ShareGate, Quest On Demand Migration and AvePoint Fly are the platforms most often considered for tenant to tenant projects, and each documents broader workload coverage than Microsoft’s native tools.

Third-party platforms exist because shared collaboration content is where native tooling stops. They add console-based setup, mapping features and, in several cases, coexistence and chat migration. The table below summarizes what each vendor publicly documents. These products change often, so treat it as a starting point and confirm current coverage with the vendor before you commit.

Platform	Workloads the vendor documents	Where it tends to fit	Worth checking
BitTitan MigrationWiz	Mailboxes, contacts, calendars, OneDrive, SharePoint sites and Teams channels, with mail-flow and free/busy coexistence	Phased projects that need coexistence and multi-workload coverage from a SaaS console	How Teams chat history is handled in your scenario
ShareGate	SharePoint, Teams (channels and conversation history), Planner, OneDrive and tenant to tenant Exchange Online mailboxes	SharePoint and Teams heavy moves where permissions and metadata fidelity matter	Mailbox scope against your requirements, such as archives and shared mailboxes
Quest On Demand Migration	Exchange Online, OneDrive, SharePoint Online, Teams, Microsoft 365 Groups, Power BI, domains, Active Directory and Entra ID, with Teams chat as an add-on	Complex mergers that include directory migration and longer coexistence	Licensing options and how many components your scope really needs
AvePoint Fly	Exchange Online, OneDrive, SharePoint, Teams, Groups, one-on-one, group and meeting chats, and shared channels	Large multi-wave migrations across several workloads, with pre-migration discovery	Wave design and the licensing model for your data volume

Two practical points before choosing. First, no platform removes the need for planning. They all depend on clean identity mapping, correct licensing and a sensible batch design. Second, plenty of organizations end up combining tools: Microsoft’s native path for mailboxes and OneDrive, and a third-party platform for SharePoint and Teams content. The question is rarely which single tool is best. It is which combination covers your scope with the least risk.

Native Tools vs Third-Party Platforms: How to Decide

Native tools usually suit user-data-centric moves run by experienced admins, while third-party platforms tend to suit migrations heavy on shared content, coexistence or tight timelines.

Factor	Microsoft native tools	Third-party platforms
Mailboxes	Supported through the Orchestrator or Exchange Online PowerShell	Supported through a guided console
OneDrive	Supported, with no incremental passes	Supported, with incremental options that vary by tool
SharePoint sites	Native, with strict site rules and an Enterprise Agreement license	Broad coverage with permission and metadata mapping
Teams chats	Through the Orchestrator (preview)	Documented by several vendors
Teams and channels	Not covered	Covered by several vendors
Coexistence	Mail routing through mail users, no full coexistence suite	Several vendors advertise coexistence features
Setup effort	App registrations, endpoints and PowerShell or Graph scripting	Console setup and connectors, though mapping is still required
Licensing	Microsoft add-on licenses	Vendor licenses on top, with models that vary
Best fit	User-data-centric moves with capable in-house admins	Shared-content-heavy or complex moves

The honest summary is that a small mailbox and OneDrive move between two clean tenants is a realistic self-managed project. Add SharePoint sites, Teams channels, compliance holds, hybrid identity or a hard deadline, and the project shifts from running a tool to running a program. That is the point where an experienced partner pays for itself.

Three Example Scenarios and the Route We Would Take

The right route follows your scope, not your company size, as these illustrative scenarios show. They are simplified examples to help you place your own project, not client case studies.

Scenario 1: a small company absorbed into a larger one

Imagine a few dozen users with mailboxes and OneDrive, no meaningful SharePoint estate and no holds. This is the friendliest case for Microsoft’s native tools, either the Orchestrator or the standalone mailbox and OneDrive paths, run as a single event. One capable admin who owns identity mapping and the domain cutover can run it. The things to watch are delegates, Teams meeting links and the timing of the domain move.

Scenario 2: two operating companies merging

Imagine a few hundred users, dozens of SharePoint sites, active Teams channels and a legal team whose mailboxes sit under hold. Here a phased migration makes sense, with coexistence so colleagues can keep working across both tenants. Native tools could handle mailboxes and OneDrive, while a third-party platform covers SharePoint and Teams, or a single platform covers everything. The hold question needs an answer before the pilot, and the SharePoint estate needs an assessment long before the first wave.

Scenario 3: a divestiture

Imagine a business unit of a hundred or so people leaving with its own domain and data. Most of the work is deciding which content goes with whom before any tool runs. Native OneDrive and SharePoint moves relocate content and leave a redirect, which suits content that is leaving entirely. For content that both organizations still need, a copy-based approach is safer. This is a tenant move or split, and the hardest part is usually shared groups and distribution lists, not the data volume.

Office 365 Tenant to Tenant Migration Step by Step

A reliable tenant to tenant migration follows eight stages: assess, prepare the target, map identities, establish trust, pilot, migrate in waves, cut over the domain, then validate and clean up.

We recommend starting your planning at least two weeks before the first batch moves. Most of that time goes on discovery and decisions, not on tools.

Step 1: Assess and scope

Inventory users, mailboxes, shared mailboxes, OneDrive volumes, SharePoint sites, Teams, groups, third-party integrations and devices. Flag everything that could block or complicate a move: mailboxes and OneDrive accounts under legal or retention holds, sites that use Purview Customer Key encryption, sensitivity labels with user-defined permissions, very large sites, and anything tied to a government cloud. Decide which approach you are using and which tools cover which workloads. This is also the time to line up compliance and legal reviewers if your data is regulated.

Step 2: Prepare the target tenant

Set up admin accounts with the right roles, apply your security baseline, buy the licenses you will need and decide how domains will move. Microsoft’s native paths need Exchange Online licensing in both tenants and the Cross-Tenant User Data Migration add-on for each migrating user. Teams chat migration also needs Teams licenses on both sides. Resist the urge to pre-create everything, though. SharePoint sites in particular must not already exist in the target, and a premature mail user setup can cause licensing problems later.

Step 3: Map identities

This is the step most projects underestimate. Every source user needs a counterpart in the target tenant, and the mapping has to stay stable while migration runs. If your team is newer to the identity side, our primer on Microsoft Entra ID basics covers the concepts behind tenants, users and sign-in. For mailbox moves, the target mail user must carry the right ExchangeGUID, ArchiveGUID and x500 address before any license is applied. Microsoft warns that licensing a mail user before those attributes are stamped can cause a brand new mailbox to be provisioned, which then complicates the migration of the real one. If you synchronize from on-premises Active Directory, plan how each tenant’s directory sync will behave during the move.

Step 4: Establish trust and permissions

For Microsoft’s native mailbox path, this means the Entra app registration, the migration endpoint, the organization relationships on both tenants and the security group that scopes who may move. For a third-party platform, it means connecting the source and target tenants with the required admin consent. Either way, document every permission you grant, because you will want to remove them cleanly afterward.

Step 5: Run a pilot

Pick a small group that reflects reality: a user with a large archive, a delegate and the person they support, someone with Teams meetings, and someone with heavy OneDrive use. Migrate them, then test the experience like a user would. Can they sign in on Outlook, find old mail, reply to old messages, open files and join meetings? A pilot finds the boring problems, such as a missing x500 address or a license applied in the wrong order, while the stakes are low.

Step 6: Migrate in waves

Design batches around relationships, not alphabetical order. Keep delegates, shared mailbox users and teams that work closely together in the same wave, because cross-tenant mailbox and calendar permissions do not carry across. Watch mailbox quotas, since mailboxes close to their limit can fail during the move. Respect queue limits for OneDrive and SharePoint, tell users when their wave is scheduled and what they will see on day one, and keep a clear escalation path for the first few hours after each wave.

Step 7: Cut over the domain and mail flow

If your email domain is moving, this is the most time-sensitive part of the project, and the order of operations matters.

• Days ahead, lower the TTL on your MX records and confirm you have DNS access.
• At the start of cutover, stop inbound mail to the source tenant or have it queued by a mail service, so senders are not bounced.
• If the source tenant is directory synced, pause that sync so late changes do not interfere.
• Release the domain from the source tenant. That means resetting addresses and objects that still use it, removing licenses where needed and clearing anything blocking its removal.
• Verify the domain in the target tenant with a TXT record.
• Update MX records, set the old addresses as primary on the target users, assign licenses and test mail flow in both directions.

Allow enough time for changes to take effect between steps. Rushing the domain removal is one of the most common reasons cutovers overrun.

Step 8: Validate and clean up

Confirm that data arrived intact, that users can work, and that mail is flowing. Then clean up: remove migration endpoints and organization relationships, revoke migration application permissions, decide whether to keep or remove the leftover mail users in the source tenant, and plan the eventual decommissioning of the source tenant. Skipping cleanup leaves both tenants with open trust relationships you no longer need. The checklist later in this guide turns this into a concrete list.

Plan for Security, Communication and Rollback

Before the first batch moves, decide how you will secure migration access, tell users what is changing and recover if a wave goes wrong, because tenant to tenant moves are hard to undo.

Security and compliance during the move

Migration access is powerful. App registrations, admin consents and migration accounts can reach a lot of data in both tenants. Use dedicated accounts, grant the least access that works, review sign-in and audit logs while the project runs, and remove everything when it ends. Microsoft’s native OneDrive and SharePoint migrations are designed so content does not leave the Microsoft 365 cloud, which simplifies some data protection questions. If your data falls under GDPR, HIPAA or similar rules, Microsoft advises consulting legal and compliance teams before you start, and we agree.

A communication plan people will actually read

Users do not need to understand tenants. They need to know what changes for them and when. Send a first message about a week ahead covering the date, what will look different and where to get help. Send a reminder the day before. On the day, tell people when to sign out and what to expect on first sign-in. The day after, confirm everything is working and point to a short guide. Be specific about the changes that surprise people: a new sign-in identity, a fresh Outlook profile, Teams meeting links that need recreating and redirected file links.

Rollback is a plan, not a button

Native moves are largely one way. The Orchestrator deletes the source mailbox after a successful migration, OneDrive and SharePoint moves leave redirects behind and cannot run incremental passes, and Microsoft’s FAQ says moving users back through the Orchestrator is not supported in preview. If you need to reverse course, you would use the standalone mailbox and OneDrive migration options. So treat rollback as a set of decisions made in advance: go or no-go criteria for each wave, a small pilot, backups or exports of critical data, and a source tenant that stays available until validation is complete.

How Long Does a Tenant to Tenant Migration Take?

There is no fixed timeline, because duration depends on user count, data volume, workloads and service load, and Microsoft itself describes its timing guidance as non-binding.

Microsoft’s Orchestrator FAQ is explicit on this point: timing information is guidance only, is not a service level agreement and varies with overall traffic, the workloads selected, the amount of data and the number of users. Users in the same batch may not finish at the same time, and different workloads for the same user can complete at different times. Plan in ranges, not promises.

What stretches a project in practice:

• Large mailboxes, large archives and heavy OneDrive or SharePoint volumes.
• Compliance holds that must be lifted and reapplied.
• Complex SharePoint structures, long paths and sites that need rebuilding after the move.
• Teams chat and channel migration, which usually adds a separate workstream.
• Hybrid identity, where each tenant’s directory sync has to be managed.
• Slow decisions, such as waiting on legal approval or DNS access.

The best way to turn uncertainty into a schedule is to run the pilot early, measure how long it really takes, and build waves and buffer time from those results.

How Much Does a Tenant to Tenant Migration Cost?

Cost depends on how many users and workloads you move, which tools you use, and whether your team or a partner does the work, so it helps to price the components separately.

A realistic budget has five parts:

• Microsoft licensing. The Cross-Tenant User Data Migration add-on for each migrating user, and, if you move SharePoint sites natively, Cross-Tenant Shared Data Migration licenses priced per 100 GB.
• Third-party tool licensing. Vendors charge in different ways, such as per user, per mailbox, per gigabyte or by subscription, so get a quote for your actual scope.
• Administrator time. Discovery, identity mapping, PowerShell or console work, user communication and post-migration support all take hours that your team would otherwise spend elsewhere.
• Risk and rework. A failed cutover or lost data costs far more than the migration itself.
• Project management. Someone has to own the plan, the schedule and the stakeholders.

What Apps4Rent charges for migration

For standalone mailbox-focused projects, Apps4Rent pricing is $100 to $150 flat for 1 to 5 mailboxes, plus $40 to $80 for each additional mailbox. Migration is often included at no extra charge with eligible Microsoft 365 annual plan purchases, and our team can tell you which plans qualify. Projects with heavy SharePoint or Teams components usually need a custom quote once we have assessed the environment. These examples show how the standalone rates scale.

Mailboxes	Estimated standalone range
5	$100 to $150
10	$300 to $550
25	$900 to $1,750
50	$1,900 to $3,750

These are illustrative figures for mailbox migration based on the rates above. Your quote depends on mailbox size, the workloads involved and overall complexity.

Do it yourself or use a managed team?

Area	Self-managed	Managed migration
Licensing	You buy, assign and track Microsoft and tool licenses	The migration team advises on and handles licensing for the project
Planning and identity mapping	Your admins build and validate the mapping	Engineers scope the project and validate the mapping before anything moves
Pilot and waves	You design batches and monitor each one	The team designs, runs and monitors the batches
Cutover	Your team coordinates DNS, mail flow and licensing	The team runs the cutover with a tested sequence
Troubleshooting	Escalated to Microsoft or the tool vendor	Handled by engineers who have seen the failure before
Risk	Sits with your team	Shared with a partner that does this regularly

If you want to compare options for your own environment, our managed migration team can scope the work and give you a quote based on your actual users and workloads.

Common Challenges and How to Avoid Them

The most common tenant to tenant migration problems are holds, identity mapping errors, licensing order, delegate permissions and Teams or SharePoint content that falls outside native tool coverage.

Compliance holds

Mailboxes and OneDrive accounts under hold are blocked from Microsoft’s native migration. Decide early whether holds can be lifted temporarily, exported or recreated in the target tenant, and involve legal before the pilot. Some tools handle held content differently, so check how your chosen platform behaves.

Identity mapping and licensing order

A wrong attribute or a license applied too early causes failures that look random. Build the mapping from one source of truth, stamp attributes before licensing, and test the exact process on pilot users first.

Delegates and shared access

Cross-tenant mailbox and calendar permissions do not survive the move. Group people who share access into the same wave and re-grant permissions as part of validation.

Teams chats, channels and meeting links

Native chat migration copies content and may leave duplicates. Channels are outside Microsoft’s user data tools altogether, and meeting links created in the source tenant may not work afterward. Decide which Teams content is truly worth moving, and communicate what users should expect.

SharePoint structure and automation

Path length, item counts, site size, sensitivity labels, workflows and web parts are the usual blockers. Run an assessment first, clean up what you can, and plan to rebuild automations. For a deeper look at site-level planning, see our guide to moving SharePoint sites between tenants.

Government clouds

Microsoft’s native tools do not support cross-cloud moves, and its OneDrive migration is not supported for government cloud users. If either tenant is in a government environment, involve a specialist early. Our explainer on how GCC and GCC High differ is a useful starting point for understanding what changes.

Day one for end users

Because the primary address moves with the domain, users typically sign in with a new identity and Outlook builds a new profile, then downloads data again. Plan for network load, send clear instructions in advance and staff the help desk for the first morning of each wave.

Quick troubleshooting reference

Symptom	Likely cause	What to check
Migration fails immediately with a license error	No Cross-Tenant User Data Migration license on the source or target user	Assign the add-on license before submitting the batch
A mailbox move is blocked	The mailbox is under a hold	Review hold policies with your compliance team
The move will not start for a user	Missing or mismatched ExchangeGUID, ArchiveGUID or x500 address on the target mail user	Compare target attributes with the source mailbox
Replies to old messages fail	The LegacyExchangeDN x500 address was not stamped on the target	Add the missing x500 address
A mailbox fails partway through	It was close to quota in the target tenant	Reduce size or enable archiving, then restart
A OneDrive move fails	A OneDrive already exists on the target, or paths exceed 400 characters	Remove the existing account or shorten paths and retry
A SharePoint move fails	The target site already exists, the source is read-only or a blocking setting is in place	Confirm site state, labels and encryption settings

Post-Migration Checklist

After the last wave completes, verify data and access, confirm mail flow, re-establish permissions and automation, and remove every temporary trust you created.

• Spot-check mailboxes, calendars, OneDrive files and SharePoint libraries against the source.
• Confirm users can sign in, that Outlook profiles are working and that old messages can be replied to.
• Recreate Teams meetings that carried source-tenant links and communicate any chat or channel changes.
• Re-grant mailbox, calendar and site permissions that did not carry across.
• Rebuild workflows, Power Platform connections and integrations that depended on the old tenant.
• Verify MX, SPF, DKIM and DMARC records and send test mail in both directions.
• Re-enroll devices and reapply Intune and security policies.
• Remove migration endpoints and organization relationships, and revoke migration application permissions.
• Decide what to do with leftover mail users in the source tenant.
• Reconcile licenses, retire what you no longer need and plan the source tenant’s decommissioning.

When a Managed Migration Makes Sense

A managed migration makes sense when your scope goes beyond mailboxes and OneDrive, when holds or government clouds are involved, or when your team cannot spare the weeks that planning and troubleshooting take.

Plenty of small, clean migrations are fine to run in-house with Microsoft’s native tools. The calculation changes when shared content, compliance, hybrid identity or a deadline enter the picture. Then the cost that matters is not the tool license. It is the experience needed to sequence the work and the risk of getting it wrong in production.

Apps4Rent is a Microsoft Cloud Solution Provider, and our engineers handle tenant to tenant migrations from assessment through cutover and cleanup. That includes scoping the project, mapping identities, selecting and running the right tools for each workload, managing the domain cutover and supporting your users afterward. If your migration is moving off a tenant you do not control, our California non-profit case study shows what that looks like in practice. And if you simply want a second opinion on your plan, we are happy to review it.

Frequently Asked Questions

1. What is an Office 365 tenant to tenant migration?

   It is the process of moving users, mailboxes, OneDrive files, SharePoint sites and other data from one Microsoft 365 tenant to another. Organizations usually do it after a merger, acquisition, divestiture, rebrand or tenant consolidation.

2. Is a Microsoft 365 tenant migration different from an Office 365 one?

   No. Microsoft rebranded Office 365 as Microsoft 365, so both terms describe the same platform. The migration process, tools and limits are the same whichever name you use.

3. Does Microsoft have a native tool for tenant to tenant migration?

   Yes. Microsoft offers the Migration Orchestrator for mailboxes, OneDrive, Teams chats and Teams meetings, plus standalone cross-tenant mailbox, OneDrive and SharePoint migration. The Orchestrator is documented as a preview, so confirm its status on Microsoft Learn before relying on it.

4. Can I migrate Microsoft Teams from one tenant to another?

   Partly. Microsoft’s native user data tools can copy Teams chats and meetings, but they do not move Teams and channels. Several third-party platforms document Teams and channel migration, or you can rebuild teams in the target tenant.

5. Can Teams chat history be migrated between tenants?

   Yes, in some cases. The Migration Orchestrator copies chats and meetings, and several third-party tools document chat migration. Native chat migration leaves the original content in the source tenant and can create duplicate threads, so test the result on a pilot group first.

6. Do I need a license for Microsoft’s cross-tenant migration?

   Yes. Each migrating user needs a Cross-Tenant User Data Migration license, a per-user one-time fee that can be assigned to either the source or the target user. SharePoint site moves use a separate per-100 GB license that is currently offered to Enterprise Agreement customers only.

7. How long does a tenant to tenant migration take?

   It depends on user count, data volume, workloads and service load, and Microsoft describes its own timing guidance as non-binding. Run a pilot early, measure it and plan waves and buffer time from the results. We recommend starting your planning at least two weeks ahead.

8. How much does a tenant to tenant migration cost?

   Apps4Rent standalone pricing is $100 to $150 flat for 1 to 5 mailboxes, plus $40 to $80 for each additional mailbox, and migration is often included with eligible Microsoft 365 annual plans. Projects with heavy SharePoint or Teams components usually need a custom quote after assessment.

9. Will users keep their email addresses and passwords?

   Email addresses can move with the domain, but the target tenant has its own identity system. Users typically sign in with a new identity and set up Outlook again, so plan communications and help desk coverage for day one.

10. Can mailboxes on legal hold be migrated?

    Not with Microsoft’s native tools. Mailboxes and OneDrive accounts on hold are blocked, so you need to decide whether holds can be lifted and reapplied, exported or recreated in the target tenant before migrating.

11. Is downtime required during a tenant to tenant migration?

    Not for the data copy itself, but the domain cutover creates a short window where mail flow changes. Lowering MX record TTL beforehand and queuing or pausing inbound mail during the switch keeps that window small.

12. Can I migrate between commercial and government tenants?

    Microsoft’s native tools do not support cross-cloud tenant to tenant migration, and its OneDrive migration is not supported for government cloud users. Some third-party platforms document specific commercial to government paths, so involve a specialist before planning one.

13. Does tenant consolidation work the same way for Google Workspace?

    No. The concepts are similar, but the tools and constraints are different. See our guide to consolidating Google Workspace accounts for that scenario.

14. When should I use a migration partner?

    Consider one when SharePoint sites, Teams channels, compliance holds, government clouds or hybrid identity are in scope, or when your team cannot spare the time to plan and troubleshoot. A small mailbox and OneDrive move between clean tenants is often manageable in-house.