How to Perform an Office 365 Tenant-to-Tenant Migration Step-by-Step

Introduction

In today’s fast-evolving business landscape, organizations frequently undergo mergers, acquisitions, divestitures, or restructuring. One of the more technically challenging aspects of this process is migrating data, user accounts, and services from one Office 365 (Microsoft 365) tenant to another. This is referred to as an Office 365 tenant-to-tenant migration.

A well‑executed migration can ensure minimal downtime, preserve data integrity, maintain user experience, and avoid disruptions. Done poorly, it can lead to lost emails, broken permissions, and frustrated users.

In this blog, you’ll get a step-by-step guide to perform an Office 365 tenant‑to‑tenant migration — including planning, execution, post‑migration cleanup, and best practices. We’ll also cover common pitfalls, tool options, and real-world tips.

1. What Is a Tenant-to-Tenant Migration & Why Do It

A tenant‑to‑tenant migration is the process of transferring users, mailboxes, sites, files, groups, and other resources from a source Microsoft 365 (Office 365) tenant to a destination tenant. The domain name (e.g. yourcompany.com) will in many instances be transferred from one tenant to another and a temporary or coordinated changeover may be needed.
Source and target tenants are different Microsoft 365 tenants that each have their own identity, configuration, and services.

Scenarios that are common

Acquisition / merge: Having combined two companies, you merge into one tenant.

Spin-off / divestiture: An Office 365 business unit is spun off as its own tenant.

Reorganize / rebrand: You desire to reorganize your tenant structure, maybe from a legacy tenant to a newly organized one.

Upgrade / clean up tenant: You might like to sunset a deprecated tenant and upgrade to a fresh, clean environment.

Compliance or regulatory purposes: e.g., separating data within new legal entity boundaries.

Benefits & Risks

Benefits:

Consolidation of identity and access management

Governing, securing, and policying in a standardized way

Cleaner, newer tenant architecture

Decreased administrative overhead

Possible cost savings on tenant licensing or subscription

Risks:

Data loss, particularly metadata, version history, permissions

Downtime for email, file access, Teams

Domain conflicts and DNS propagation delays

Broken links, broken permissions, misconfigurations

User frustration and support burden

Due to these dangers, planning is deliberate, phased execution is required, and significant validation must be undertaken.

2. Pre‑Migration Planning

Proper planning must take place before you even lay a hand on any tenant configurations. This process usually determines whether the migration will be successful or not.

Stakeholder Alignment

All stakeholders must be identified: IT, security, compliance, business units, legal, communications, and user support.

Define success criteria: What does a “successful migration” mean? (e.g. zero data loss, <2 hours downtime)

Assign responsibilities and roles: project manager, migration leads, technical owners, support team.

Establish achievable timelines and milestone dates, with buffer time for unforeseen delays.

Inventory & Audit

You need to know intimately what you are migrating:

Number of users, mailboxes, mailbox size

SharePoint / OneDrive usage, number of sites, site sizes, document libraries

Teams usage: channels, files, chats, apps

Distribution groups, shared mailboxes, resource mailboxes

Custom applications or third-party integrations associated with the source tenant

Domain names, aliases, email addresses, SMTP configurations

Policies, security settings, compliance, retention labels

Active Directory synchronization (if on‑prem Hybrid) or Azure AD Connect pipelines

This audit will assist you in gauging complexity, costs, potential blockers, and time needed.

Licensing & Subscriptions

Make sure your target tenant has enough licenses to cover all users, mailboxes, and services prior to migration.

Check if the same, higher, or lower SKU licenses are required for users after migration.

Understand any add-on or premium services (e.g. Power Platform, Azure, compliance features) which might need to be reconfigured in the target tenant.

Domain Planning

Because domains are central to email and UPNs, domain planning is paramount:

List all domains utilized in the source tenant (primary domain, alias domains)

Determine which domains will be migrated to the target tenant

Understand domain deletion limits (you can’t delete a domain that’s being utilized by accounts or objects)

Plan for DNS changes, target domain verification, and cutover timing

Plan for MX (mail exchanger) DNS changes and TTL reduction to limit DNS propagation delay

Risk Assessment & Fallback Strategy

Determine risks: data corruption, permissions loss, longer downtime, domain verification failure, DNS propagation delay

Plan fallback alternatives: capability to reverse mail flow, maintain old tenant alive for some time, snapshots for backup

Choose to migrate pilot or test migration first

Plan delta / incremental migration by phases

Communication Plan

Notify end users early: migration date/time, estimated downtime, what’s changing

Make available training materials, FAQs, list of known issues

User support scheduling (helpdesk, office hours, triage) after migration

Regular status reports to stakeholders during migration

3. Preparation Phase

With your plan underway, begin configuring source and target tenants for migration.

Domain Verification & DNS Setup (Target Tenant)

In the target tenant, enter the domain(s) you plan to transfer (e.g. contoso.com).

Create a TXT record in DNS (either at the domain registrar or DNS host) in order to confirm domain ownership.

Tip: If the domain is actively used in the source tenant, complete verification might not be achieved until you delete it there.

Wait for DNS propagation (can take up to 72 hours) for the verification process to finish.
SysTools
+2
BitRecover
+2

If you do either Domain Connect or name server delegation, use those procedures if your DNS provider has them.
SysTools

User Account & Directory Sync Considerations

If using Azure AD Connect / AD DS hybrid:

Determine if you will migrate identities (i.e. sync the same user accounts to the target tenant) or handle them as cloud-only new users.

If migrating identities, prepare to de-sync or re-configure AD sync, attribute conflicts, and password sync.
techverx.com
+2
DuoCircle
+2

If using password hash sync or pass-through, make sure users can login with same credentials after migration.

If you are not using AD sync:

You will create new user accounts in target tenant (in .onmicrosoft domain or dummy domain) and then switch to correct domain after migration.

Data Backup

Before migrating anything

Take complete backups or snapshots of mailboxes, SharePoint sites, OneDrive files, etc.

Securely store backups and test restore of a few items to ensure integrity.
email-security.s3.us-south.cloud-object-storage.appdomain.cloud

Backup configurations (policy, groups, settings) particularly for compliance or custom settings.

Cleanup & Trimming

Reducing what you move decreases risk and time:

Remove unused mailboxes, groups, and aged accounts

Archive or purge redundant, old, or irrelevant data

Verify mailboxes or items in litigation hold—some utilities might not move them automatically
Reddit
+1

Remove email addresses, alias settings, and personalized configurations

4. Migration Execution – Step by Step

Here comes the meat of the migration: the migration of everything from source to target in a choreographed manner.

Prepare the Source Tenant

Turn directory sync off (if enabled) so AD changes do not propagate during migration. This operation might take ~24 hours.
DuoCircle
+3
SysTools
+3
BitRecover
+3

Erase the primary domain from every user UPN, aliases, distribution lists, resource mailboxes. You might have to revert addresses to default .onmicrosoft.com addresses.
SysTools
+2
BitRecover
+2

Erase any Lync / Skype for Business / Teams licensing or object associations by using the domain.
SysTools
+2
DuoCircle
+2

Verify using PowerShell for objects that still utilize the domain (e.g. Get-MsolUser -DomainName domain.com) and fix.
SysTools
+1

Modify TTL (Time to live) of MX records to lowest feasible value in DNS (e.g. 300 seconds) to reduce propagation delay during cutover.
DuoCircle
+3
BitRecover
+3
Communication Square LLC
+3

Stop or reroute incoming mail so new incoming emails can queue until it’s delivered to target tenant (more in subsequent step).

Prepare the Target Tenant

Confirm domain in target tenant (if not already completed).

Create shared mailboxes, resource mailboxes, distribution lists, security groups in target tenant.

License users in target tenant.

Setup autodiscover CNAME record in DNS, and any other crucial DNS records for email, etc.
SysTools
+2
DuoCircle
+2

When using ADFS or federated identity, set up new domain in target for federation.

Set up mail routing and transport rules in target tenant to accept inbound email as soon as MX changes.

Test email sending/receiving in the target environment through a test mailbox.

Mailbox Migration

Mailbox moving typically has the highest priority. You need to maintain folder structures, calendar entries, contacts, and rules.

Methods:

Pre-stage / staged migrations: Transfer most content in advance, followed by final sync (delta migration) prior to cutover. This keeps downtime to a minimum.
kasnowicka.com
+2
DuoCircle
+2

Bulk / burst migration: In smaller installations, you may transfer everything at once.

Steps:

Establish a migration endpoint between the target tenant and the source (e.g. through Exchange Online remote move). (In cross-tenant mailbox migrations, you usually create a remote move endpoint.)
YouTube
+2
Office 365 Computing
+2

Create migration batches (CSV files that map source to target mailboxes) to manage how many mailboxes migrate in parallel.
Microsoft Learn
+2
techverx.com
+2

Initiate migration batches, track progress, fix errors (e.g. duplicate aliases, permission problems).

After most of the data is moved, do a delta / incremental sync to pick up changes since the first migration.

Verify mailbox data on target: folder counts, item counts, calendar items, rules, etc.

Temporarily send email forwarding or redirection rules from source to target, optionally.

4.4 SharePoint, OneDrive, Teams & Other Workloads

Other workloads may be harder to migrate owing to dependencies, permissions, metadata, and integration.

OneDrive / SharePoint:

Use the built-in tools of Microsoft (e.g. SharePoint Migration Tool) or third-party tools (e.g. ShareGate, AvePoint) to migrate site collections, document libraries, metadata, versions, and permissions.
Reddit

Keep permissions, sharing links, version history if available

After migration, replace links, refactor URLs, handle redirects if necessary

Microsoft Teams:

Teams is complicated: channels, files, chats, apps, tabs. Not all of the tools will migrate private chats.

Migrate files located in Teams (e.g. underlying SharePoint) using migration tools

Migrate teams, channels, tabs, apps, settings

Certain migration tools offer specialized Teams migration support

Reconfigure apps, integrations, connectors after cutover

Other Workloads:

Planner tasks, Power Apps, Power Automate flows, mail flow rules, compliance settings

Update integrations or third-party applications to point to the target tenant

Migrate distribution lists, resource mailboxes, shared mailboxes

Permissions, Groups & Resources

Migrate security groups, distribution groups, mail-enabled security, and membership.

Rebuild or duplicate permissions (folder permissions, SharePoint permissions, teams, etc.).

For groups and roles, provide target users access identical to source.

For shared mailboxes and resource mailboxes, move contents and access.

Final Sync & Cutover

Run a final delta sync to collect all changes since the previous migration pass.

Flip MX records in DNS to deliver inbound mail to target tenant. Because you’ve set TTL low, propagation should be quicker.

Watch mail flow in target tenant.

Final validation: verify users can send/receive, access files, open Teams, etc.

Disable mail forwarding, eliminate temporary redirects.

Verify user UPNs and email addresses are changed to utilize the proper domain in the target tenant.

5. Post‑Migration Tasks & Validation

Once migrated, verify that everything is in order and eliminate remaining artifacts.

Testing & Validation

Verify mailbox item count, folder structures, calendar entries, contacts, tasks

Verify sending/receiving external and internal emails

Verify permissions and access to shared mailboxes, distribution lists

Verify SharePoint sites, navigation, library access, sharing links

Verify Teams: channels, files, tabs, meetings, apps

Verify integrations and third-party apps

Utilize reporting tools to verify data counts cross-checked

Schedule periodic audit logs and monitor errors

DNS, MX & Mail Flow

Verify MX records are fully propagated

Monitor for any email bounce backs or routing problems

Check SPF, DKIM, DMARC records are properly configured in the new tenant

Remove or modify any mail flow connectors or rules from the old tenant

Decommission Old Tenant & Cleanup

Wait an appropriate grace period prior to decommissioning

Archive or export data still within the old tenant

Remove domains from old tenant completely, once you’re sure everything is migrated

Cancel or transfer subscriptions/licensing on the source tenant

Clean up residual accounts, policies, settings

Training & User Support

Host training sessions or workshops for end users

Provide quick reference guides, FAQs, support resources

Open helpdesk channels, respond to issues promptly

Monitor feedback, user complaints, and fix broken items

Monitoring & Troubleshooting

Monitor logs, alerts, and usage analytics in the new tenant

Use Microsoft’s monitoring and reporting dashboards

Resolve any delayed syncs, missing items, or permission discrepancies

Be prepared to troubleshoot DNS, authentication, or application access issues

6. Best Practices & Tips

Here are some best practices and tips to increase success:

Pilot first: Begin with a limited group of test users to test your process

Set low TTLs: Set low DNS TTLs well in advance of the cutover to decrease propagation delay

Use delta migrations: Leverage incremental syncs to decrease downtime

Migrate off-peak or on weekends: less user impact

Communicate often: Keep stakeholders, users in the know

Validate at each phase: Don’t wait until the end to find issues

Backup everything: Never go live w/o backups

Expect edge cases: Litigation hold mailboxes, third-party integrations, custom apps might require special treatment

Document in detail: Scripts, settings, mapping, decisions

Manage expectations: Some items (e.g. Teams private chats) might not migrate in all tools

Use vendor or consultant assistance for large migrations: When scale or complexity is great

Also Check: 2000+ High DA PA Profile Creation Sites List 2025

7. Common Challenges & How to Mitigate

Challenge\tPotential Impact\tMitigation / Solution
Domain can’t be validated in target tenant since it’s still linked in source Blocked migration Remove domain from source objects first, then validate in target DNS propagation delays Email downtime or bounce backs Lower TTL in advance, buffer time Failed mailbox migration (permissions, alias conflicts) Partial migration or missing data Monitor error logs, resolve conflicts, re-run migration batches Loss of metadata / version history / permissions User dissatisfaction, broken collaboration Use advanced migration tools, map permissions with care
Teams private chat not migrated
Missing conversation history
Alert user beforehand, save as historical record
Third-party integration breakage
Application failures
Inventory integrations, reconfigure post-migration
Identity or login issues
Users can’t access accounts
Test credentials, plan directory sync carefully, reconfigure login methods

One real-world comment from community experience:

“Teams’s chats can’t be moved, so BitTitan archived them in an Outlook folder for the user.”
Reddit

“Domain can’t be added to target until removed from source — scheduling downtime is critical.”
Reddit

So always add buffer time and user communication for “known limits.”

8. Tooling Options (Native vs Third‑Party)

You can migrate with Microsoft’s native tools or third-party migration tools. The appropriate choice varies depending on scale, complexity, and budget.

Native Tools

Exchange Online cross-tenant migrations (remote move)

SharePoint / OneDrive migration tools

PowerShell scripts

Microsoft 365 Admin Center tools for domain, users, etc.

Pros: Low price (no additional licensing), backed by Microsoft
Cons: Capable only (metadata, permissions, Teams, apps), more manual configurations, greater risk for complex situations

Third-Party Tools

9. Summary & Checklist

Moving an Office 365 tenant to another is a high-risk procedure that needs strategic planning, cautious execution, and complete verification. The process includes:

Pre-migration planning: inventory, licensing, domain, risk, communication

Tenant preparation: domain verification, disable sync, backups

Migration steps: source readiness, target configuration, mailbox migration, services migration (SharePoint, Teams), permission migration

Cutover & final sync

Post-migration: verification, cleanup, training, monitoring

Following best practices—pilot migrations, fallback planning, clear communications, tool choice—will dramatically boost your success rate.

Migration Checklist (Abbreviated)

Following is a high-level checklist you can use as you implement:

Stakeholders identified and aligned

Inventory and audit complete

Target tenant has necessary licenses

Domain list and plan for domain transfer

Communication plan prepared

Backups taken and verified

Cleanup (delete unused accounts, data)

DNS TTLs lowered ahead of time

Domain verified in target (if possible)

Directory sync disabled in source

Users created and licensed in target

Mailbox migration endpoint configured

Migration batches run, delta sync done

Services (SharePoint, OneDrive, Teams) migrated

Permissions, groups, resources migrated

MX records updated

Validation and testing done

Old tenant decommissioned

User support, training, monitoring

You can print, export, or use this checklist as a convenient guide throughout your migration.

Get Daily Tech News Here

AOSP

Search Form