Microsoft 365 tenant-to-tenant migration: complete step-by-step guide to move between tenants without data loss

Quick summary: Microsoft 365 tenant-to-tenant migration in 7 key points

1. When it is required: mergers and acquisitions, rebranding or domain change, partner change, carve-out or spin-off, consolidation of multiple Office 365/Microsoft 365 tenants into a single environment.
2. What workloads move: Exchange Online (email and calendars), OneDrive, SharePoint, Microsoft Teams, Intune-managed devices, Power Platform automations (Power Apps, Power Automate, Power BI) and security/compliance policies.
3. What Microsoft uses today: CTUDM (Cross-Tenant User Data Migration) for mailboxes and OneDrive, cross-tenant Entra ID features, native SharePoint migration capabilities and complementary tools when needed.
4. Project pillars: honest assessment of the current environment, well-designed coexistence, security and compliance from day one, and a carefully rehearsed domain move.
5. Typical risks: late CTUDM purchase, improvised domain move, underestimating Power Platform, broken OneDrive/SharePoint links, missing retention and labelling policies in the target tenant, insufficient user communication.
6. Effort and roles involved: IT, security, business (process owners), legal/compliance in regulated sectors and, in many cases, a specialised partner that coordinates both the technical work and change management.
7. When it makes sense to rely on a partner: when the organisation is going through M&A, when there are strong regulatory requirements, when there are multiple legacy tenants or when you want to minimise the risk of disruption and data loss.

When do you need a Microsoft 365 tenant-to-tenant migration?

Not every organisation needs a Microsoft 365 / Office 365 tenant-to-tenant migration. However, there are very clear scenarios where this type of project becomes almost unavoidable. Identifying your own scenario helps to understand the level of effort, the risks and the available options.

Typical scenarios

• Mergers and acquisitions (M&A): one company acquires another that already uses Microsoft 365. There are two tenants and the goal is to consolidate people, email, documents and security into a single environment.
• Carve-out or spin-off: part of the business is separated and needs its own tenant (new legal entity, new domain, new leadership team), moving only a subset of users and data.
• Rebranding or corporate domain change: the brand name and email domain are changed across the organisation, which forces a review of domains, UPNs and identities.
• Consolidation of legacy tenants: there are several Office 365/Microsoft 365 tenants inherited from previous acquisitions and the organisation wants to simplify management, licensing and governance.
• Partner or licensing model change: the CSP/partner is changed and the company decides to reorganise the tenant or move part of the organisation to another tenant where decisions are centralised.
• Global reorganisation: multinational groups that want to move from a country-based model to a regional or corporate model, unifying tenants by region or line of business.

In all these cases, the practical question is not just “how to migrate”, but “what to migrate, what to leave in the source tenant, what to rebuild from scratch and in which order to do it” to minimise the impact on operations.

Introduction to Microsoft 365 tenant-to-tenant migration

This guide walks you step by step through a Microsoft 365 tenant-to-tenant migration without data loss. Each phase —assessment, coexistence, CTUDM licensing, Exchange, OneDrive/SharePoint, Teams, Intune and DNS— is explained with clear guidance, examples and official references. The goal is to make go-live predictable, ensure adoption flows smoothly and keep risk under control.

The need for a Microsoft 365 tenant-to-tenant migration or an Office 365 tenant-to-tenant migration typically arises in very specific scenarios: mergers and acquisitions, business carve-outs, internal reorganisations, partner changes or the consolidation of multiple tenants into a single one to simplify management. In all these cases, it is not just about moving mailboxes or files: it is about moving the way teams work, collaborate and share information.

That is why, beyond the technical side, this guide focuses on the business perspective and the impact on people: what users will notice in their day-to-day work, how to reduce friction when adopting the new tenant and which decisions should be agreed with leadership before changing anything. The aim is for this guide to become a practical roadmap for IT, security and data governance teams planning a Microsoft 365 tenant change.

Throughout the article you will see concepts such as Cross-Tenant User Data Migration (CTUDM), Entra ID (formerly Azure AD), Exchange Online, OneDrive, SharePoint, Teams, Intune and Microsoft Purview. We explain when they come into play, why they matter and which best practices to follow in a modern Office 365 / Microsoft 365 tenant-to-tenant migration.

1. Project methodology and governance

In practice: the goal of the methodology is to make the Microsoft 365 tenant-to-tenant migration predictable, measurable and understandable for both IT and the business.

A solid methodology reduces friction, improves communication with business stakeholders and accelerates adoption. Working in waves allows you to learn with a pilot, scale with confidence and reserve a well-rehearsed final cutover. In a Microsoft 365 tenant-to-tenant migration, coordination issues often have more impact than purely technical errors.

MSAdvance delivers in waves: representative pilot → progressive waves → cutover and stabilisation. Each wave includes business validation (UAT), synchronisations where applicable, metrics and role-based communication.

A common approach is to combine agile practices with a milestone-based plan: kickoff workshops, architecture design, technical execution and adoption phase. For each phase, responsibilities, approvers and expectations are clearly defined, so that the migration is not perceived as a “pure IT project”.

Good project governance also includes a steering committee (weekly or bi-weekly) with representatives from IT, business and security, where risks, dependencies and pending decisions are reviewed. This prevents key topics like legal hold, information classification or device management from being pushed “to the end”.

2. Assessment: inventory, dependencies and limits

In practice: the assessment answers “what is there”, “what can be moved” and “what blocks a smooth Office 365 tenant-to-tenant migration”.

The initial inventory sets the accuracy of the plan. This is where you detect blockers (holds, special permissions) and size waves and timelines before moving a single byte. A Microsoft 365 tenant-to-tenant migration without a rigorous assessment usually leads to last-minute surprises and conflicts between teams.

It is also recommended to document regulatory requirements (financial sector, healthcare, public sector, etc.) and data location (datacentre regions) to confirm that the target tenant complies with the organisation’s data residency policies.

A good assessment outcome is a dependency map: which applications depend on email, which business processes use Power Automate flows, which areas share SharePoint sites and which users are particularly sensitive to change (leadership, customer service, 24×7 operations, etc.). This map will help prioritise waves and prepare a realistic communication plan.

3. Coexistence: identity, Free/Busy and email

In practice: well-designed coexistence allows the business to keep working while IT moves data between Microsoft 365 tenants.

Coexistence ensures the organisation can continue operating during the migration. With identity, calendars and email aligned, interruptions are reduced to a minimum. For end users, the ideal is that the tenant change feels like an adjustment rather than a full relocation.

3.1 Identity (Entra ID)

It is recommended to enable Cross-tenant access for B2B collaboration and, if you need to automate provisioning/updates, to use Cross-tenant synchronization to provision B2B guests with mapped attributes.

• Cross-tenant synchronization (overview)
• Configure cross-tenant synchronization

A best practice is to define in advance how User Principal Names (UPN) and email aliases will look in the target tenant. This avoids unnecessary address changes for users and simplifies external communication with customers and suppliers.

3.2 Calendars (Free/Busy)

It is recommended to configure Organization Relationships in Exchange so that both tenants can see availability during coexistence.

Connect-ExchangeOnline
New-OrganizationRelationship -Name "Rel-Target-Tenant" `
  -DomainNames "contoso.com" -FreeBusyAccessEnabled $true `
  -FreeBusyAccessLevel LimitedDetails

For the business, the key is being able to schedule meetings normally during the migration. Before each wave, it is worth testing that calendars between source and target tenants correctly display availability (Free/Busy), especially in critical areas like sales, support or leadership.

3.3 Email and routing

It is usually a good idea to keep MX pointing to the source tenant until cutover. If temporary rerouting is needed, you can use well-controlled connectors and rules and rehearse end-to-end mail delivery.

In complex scenarios (for example, multiple domains or subsidiaries), it is useful to document clearly which domains move, in which order and how email will behave in each phase. A simple routing flow diagram saves a lot of questions for first-line support.

4. CTUDM licensing and legal considerations

In practice: CTUDM is the key building block for a Microsoft-supported Office 365 tenant-to-tenant migration, but it requires licensing and compliance planning.

The native path requires the Cross-Tenant User Data Migration (CTUDM) add-on per migrated user (covering mailbox and OneDrive). It is a “one-time use” per migrated object. We recommend planning purchases in advance and validating compliance (GDPR, audit, retention) before starting the Microsoft 365 tenant-to-tenant migration.

From a legal perspective, migrating personal data between tenants usually implies reviewing data processing agreements, partner contracts and compliance documentation. It is important that the legal department understands what information moves, in what timeframe and with what security guarantees, especially in organisations subject to external audits.

Although there are alternative strategies (PST exports, IMAP migrations or other approaches), CTUDM gives you official support, traceability and lower operational risk. In general, those alternatives should be reserved for residual or exceptional scenarios, not as the primary strategy.

Costs and effort in a Microsoft 365 tenant-to-tenant migration

The cost of a Microsoft 365 tenant-to-tenant migration is not limited to CTUDM licences. Other factors include:

• Number of users and mailboxes to migrate.
• Data volume in Exchange Online, OneDrive and SharePoint.
• Complexity of Power Platform, integrations and third-party applications.
• Number of Intune-managed devices and legacy systems.
• Regulatory, audit and data retention requirements.
• Need for extended support, training and change management.

This is why many organisations choose a mixed approach: part of the effort is handled by the internal IT team and part is delegated to a specialised partner who has already delivered other Microsoft 365 cross-tenant migration projects.

5. Migrating Exchange Online between Microsoft 365 tenants

In practice: in Exchange Online the objective is to keep email flowing and ensure users barely notice they have changed tenants.

Migrating email in an orderly way minimises incidents and support tickets. Working with well-defined batches and synchronisations before cutover lets you arrive at day zero with everything already replicated. In an Exchange Online tenant-to-tenant migration, batch design often makes the difference between a calm cutover and an endless weekend.

1. Trust and consent: meet all prerequisites in the official guide.
2. Target identity: make sure the user exists/maps in the target tenant (B2B or local account).
3. Migration batches: use New-MigrationBatch with CSV and enable synchronisation until cutover.
4. Post-cutover: validate rules, delegations, shared mailboxes and SMTP flows.

It is advisable to place critical users (leadership, 24×7 operations, customer-facing teams) in separate batches so you can provide closer support. It also helps to label each batch with a clear identifier (by department, country or business unit) to read reports and correlate incidents more easily.

Connect-ExchangeOnline
$csv = [System.IO.File]::ReadAllBytes("C:\ctm\users.csv")
New-MigrationBatch -Name "CTM-Wave-01" -CSVData $csv `
  -TargetDeliveryDomain "contoso.mail.onmicrosoft.com" -AutoStart -AutoComplete:$false
Get-MigrationBatch -Identity "CTM-Wave-01" | Get-MigrationUser | Get-MigrationUserStatistics -IncludeReport

Before closing mailboxes in the source tenant for good, it is best practice to keep an observation window, review that no strange bounces appear and confirm with the business that all distribution lists, resource mailboxes and shared mailboxes are working as expected.

How to migrate Exchange Online between tenants (in practice)

Using Microsoft native tools (CTUDM)

1. Prepare the relationship between tenants: configure cross-tenant access in Entra ID and review the Cross-tenant mailbox migration prerequisites (permissions, verified domains, etc.).
2. Define endpoint and batches: from Exchange Online PowerShell, create the migration endpoint and batches using New-MigrationEndpoint and New-MigrationBatch (as in the example above).
3. Sync before cutover: keep batches in incremental sync until the agreed change window.
4. Cutover and validation: during cutover, complete the batches, review bounces, delegations, shared mailboxes and transport rules.

Using third-party tools (Quest, BitTitan, etc.)

When the project is very large or you need advanced reporting, CTUDM is often combined with third-party solutions:

• Quest On Demand Migration (Exchange): connects both tenants, discovers mailboxes, maps identities, creates waves and provides dashboards with status per mailbox, errors and retries.
• BitTitan MigrationWiz (Mailbox Project): lets you create mailbox projects, configure source/target endpoints, import users via CSV, run a pre-stage (90–95% of mail) and then perform a final cutover.
• Other vendors: there are similar tools focused on specific scenarios (archive mailboxes, extended coexistence, audit-heavy requirements, etc.).

Official Microsoft documentation: Cross-tenant mailbox migration (Exchange Online).

6. Migrating OneDrive between Microsoft 365 tenants

In practice: with OneDrive, the biggest risk is not moving files, but shared links and user expectations about “where my stuff is”.

OneDrive typically contains day-to-day working files, personal drafts and documents that have not yet found their permanent home in SharePoint. Defining how to handle versions and sharing avoids nasty surprises “the day after” the migration.

Cross-tenant OneDrive migration moves user content to the target tenant. It is advisable to plan how to handle external links and to explain to users what will happen with existing links, especially those shared with customers and suppliers.

1. Set up trust and permissions between tenants.
2. Pre-create users/groups in the target tenant and map identities.
3. Run per-user moves and validate access, versions and sharing.

From the user’s perspective, it is important to clarify that files do not “disappear” but move to another tenant. A short visual guide with screenshots showing how to find their new OneDrive, how to check the “Shared” section and how to re-share key documents usually prevents a lot of support tickets.

How to migrate OneDrive between tenants (in practice)

Using Microsoft native tools (CTUDM)

1. Prepare cross-tenant permissions: enable the Cross-tenant user data migration scenario in Entra ID and in the OneDrive admin centre.
2. Validate target OneDrive: check that users exist in the new tenant, have licences assigned and their OneDrive has been provisioned.
3. Configure mappings: for each user, define source and target (usually via CSV or scripts) and launch the migration from the admin centre or via PowerShell depending on the available option.
4. Verify content and sharing: review versions, critical folders and internal sharing; for external links, agree with the business which files must be re-shared after the migration.

Using third-party tools (Quest, BitTitan, etc.)

In organisations with a lot of OneDrive content, specialised document migration tools are common:

• Quest On Demand Migration (OneDrive): discovers source OneDrives, maps target users and moves content while preserving permissions and sharing where the API allows it.
• BitTitan MigrationWiz (Document Project): creates projects by batches, defines endpoints, imports users and runs phased migrations, with per-user and per-file reports.

7. Migrating SharePoint Online between Microsoft 365 tenants

In practice: with SharePoint, the focus is on preserving the site structure, permissions and automations that support key business processes.

SharePoint hosts critical libraries, automation workflows and complex permission models. It is essential to audit and design how the structure will look in the target tenant to preserve productivity and security. For many organisations, a significant portion of the intranet, project documentation and internal procedures live in SharePoint.

Cross-tenant site migration is available with specific capabilities (you should review its current status and limits). Alternatively, you can use tools that support advanced permission and information architecture mapping.

• Audit sites (owners, inheritance, apps, real usage).
• Decide how to handle versions and shared links.
• Plan an access recertification after the move.

A good time to plan a SharePoint tenant-to-tenant migration is when the organisation also wants to tidy up its site ecosystem: archive what is no longer needed, consolidate overly fragmented sites and establish a clear structure (by department, country, product, etc.) with hub sites and naming rules.

How to migrate SharePoint Online between tenants (in practice)

Using Microsoft native tools

1. Classify sites: identify team sites, communication sites, hubs and their dependencies (Power Automate, Power Apps, etc.).
2. Configure the cross-tenant scenario: prepare the relationship between tenants and follow the Cross-tenant SharePoint migration prerequisites.
3. Use Migration Manager / APIs: from the SharePoint admin centre, define site and library migration jobs, or use migration APIs when you need more automated flows.
4. Validate permissions: after the move, review owners, members and visitors, as well as external sharing and public links.

Using third-party tools (Quest, BitTitan, etc.)

• Quest On Demand Migration (SharePoint): discovers sites and site collections, maps them to target structures, migrates content, permissions and some customisations, with detailed reporting.
• BitTitan MigrationWiz (Document/SharePoint): creates projects per site or site collection, defines content filters and schedules migrations to minimise impact.

Official Microsoft documentation: Cross-tenant SharePoint migration.

8. Migrating Microsoft Teams between Microsoft 365 tenants

In practice: in Teams, the important thing is to preserve key workspaces (teams and channels) and manage expectations about which conversations will be retained.

Teams brings together files, chats, meetings and apps. Moving files, recreating key workspaces and training each role usually works well to preserve continuity. Decisions about what to replicate and what to rebuild from scratch directly influence whether the post-migration experience feels orderly or chaotic.

• Identify teams by process (sales, finance, projects) and criticality.
• Recreate governance (naming, expiration, guests) in the target tenant.
• Plan for recordings (Stream on SharePoint) and integrated tabs/apps.

It is important to explain that some elements, such as 1:1 chats or very old channel conversations, may not be migrated natively in every scenario. In those cases, you can keep the source tenant available for a defined period or export specific evidence if there are legal or audit requirements.

How to migrate Microsoft Teams between tenants (in practice)

Using Microsoft native tools

As of today, there is no native wizard that fully and automatically migrates all Teams teams, channels and chats between tenants. The strategy usually combines:

• Files and tabs: migrate the files associated with Teams using SharePoint/OneDrive migration (documents are stored in SharePoint sites).
• Teams and channels: recreate teams and channels in the target tenant, manually or via PowerShell/Graph.
• Channel messages (optional): where compliance requires it, use the Teams migration APIs to import historical messages into the new tenant.

Connect-MicrosoftTeams

$newTeam = New-Team -DisplayName "Sales EU" -MailNickname "sales-eu"
New-TeamChannel -GroupId $newTeam.GroupId -DisplayName "General"

Using third-party tools (Quest, BitTitan, etc.)

To simplify the work, many organisations use specialised Teams migration solutions:

• Quest On Demand Migration (Teams): discovers teams, channels and members, maps them to target groups and migrates files, tabs and parts of the history according to API capabilities.
• BitTitan MigrationWiz (Teams): creates Teams projects, maps source/target teams, migrates files, tabs, members and, in some cases, channel conversations.

Official Microsoft documentation (Teams migration APIs): Import third-party platform messages to Teams.

9. Power Platform and other workloads (Power Apps/Automate/BI)

In practice: the goal in Power Platform is to ensure automated processes do not break due to credential, connector or environment changes.

Many automations depend on credentials and connectors with permissions that will change tenant. Before cutover, it is critical to review owners and dependencies. A Microsoft 365 tenant-to-tenant migration that ignores Power Platform can break key processes with no warning for users.

• Inventory of critical apps/flows and business owners.
• Re-authentication of connections and credential updates in the target tenant.
• End-to-end testing with sample data and user validation.

It is also a good idea to define an environment strategy (development, test, production) in the new tenant if one does not exist. This way, any new automation created after the migration will follow a more controlled lifecycle aligned with data governance policies.

How to migrate Power Platform between tenants (in practice)

Using Microsoft native tools (ALM and solutions)

1. Convert apps and flows into solutions: package Power Apps, Power Automate flows and related components into managed or unmanaged solutions.
2. Export from the source environment: download the solution (ZIP) from the Power Platform admin centre or use pipelines/DevOps.
3. Import into the target environment: upload the solution into the new tenant environment, resolve dependencies (connectors, roles, Dataverse tables, etc.) and apply updates.
4. Update connections and credentials: reconfigure connectors (SharePoint, Exchange, SQL, etc.) with accounts and permissions from the new tenant.

Using third-party tools or advanced automation

In scenarios with many environments and solutions, you can complement this with:

• Power Platform pipelines / Azure DevOps / GitHub: to automate export and import of solutions across environments and, where appropriate, tenants.
• Scripts with PowerShell and Power Platform CLI: to standardise recurring tasks such as exporting solutions, applying environment variables or enabling/disabling flows.

Official Microsoft documentation: Move resources between Power Platform environments or tenants · Microsoft Learn: Power Platform.

10. Migrating devices and Intune between Microsoft 365 tenants

In practice: with Intune, the key is that devices continue to comply with policies and users can work without unexpected blocks.

You need to define whether you will use re-enrolment, Autopilot from scratch or a gradual migration. The aim is to maintain access and security policies with minimal friction for end users, especially for field teams or remote workers.

• Export configuration and recreate equivalent policies in the target tenant.
• Evaluate Windows Autopilot (import hardware hashes, profiles in the new tenant).
• Plan the user experience (un-enrolment and join to the new tenant).

It is recommended to distinguish between corporate devices and BYOD (user-owned devices). For BYOD devices, clear communication is essential: what will be done, how their personal data will be affected and which steps they must follow to re-register the device if necessary.

How to migrate devices and Intune between tenants (in practice)

Using Microsoft native tools

There is no fully automated “Intune tenant-to-tenant migration”. In practice, the strategy is to recreate configuration in the new tenant and re-enrol devices:

1. Export configuration: document or export compliance policies, profiles, apps and settings from the source tenant so you can recreate them in the target tenant.
2. Prepare the new tenant: create equivalent groups, policies and profiles, configure Intune, Defender and, if applicable, co-management with Configuration Manager.
3. Use Windows Autopilot where possible: register devices in Autopilot in the new tenant and plan an Autopilot reset or reprovisioning so that they leave the old tenant and join the new one.

Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile .\AutopilotDevices.csv

4. Re-enrol existing devices: for devices that cannot be reprovisioned from scratch, coordinate with users to disconnect the device from the source tenant and join it to the new tenant (for example, using the Company Portal app and the “Connect to work or school” wizards).

Using third-party tools

Some migration platforms (for example, M365-focused Quest solutions) help automate inventories, script generation and reporting, but the key step is still re-enrolling the device in the new tenant.

Official Microsoft documentation: What is Microsoft Intune · Windows Autopilot.

11. Domain move: verification, TTL and DNS

In practice: the domain move is the most visible moment in a tenant-to-tenant migration: if it goes well, email barely stops; if it is improvised, the impact multiplies.

The domain change is the visible “cut”. Rehearsing it, lowering TTL ahead of time and preparing DNS records so that the transition is smooth has one of the biggest impacts on how the project is perceived.

# MX to Exchange Online Protection
MX @ 0 → contoso-com.mail.protection.outlook.com

# SPF / DKIM / DMARC
TXT @ "v=spf1 include:spf.protection.outlook.com -all"
CNAME selector1._domainkey → selector1-contoso-com._domainkey.contoso.onmicrosoft.com
TXT _dmarc "v=DMARC1; p=quarantine; rua=mailto:dmarc@contoso.com"

The success of the domain move is measured in minutes: how long it takes for email to stabilise, how many bounces appear and how many incidents the service desk receives. Having a clear rollback plan, even if you never need to use it, provides reassurance to both IT and leadership.

Guides: Remove a domain · Add a domain · DNS records for Microsoft 365

12. Security and compliance: MFA, Conditional Access, Purview

In practice: migration is a great opportunity to raise the security baseline of the target tenant and close inherited gaps.

It is essential to harden the target tenant from day one. Avoiding insecure shortcuts after migration is key to sustain change and not open temporary gaps that later become hard to close. A Microsoft 365 tenant-to-tenant migration is the right moment to raise your security posture.

The technical work should be accompanied by training on security best practices: how to spot suspicious emails, what to do in case of a suspected phishing attack, how to share documents securely, etc. A few well-designed sessions greatly reduce human risk after the tenant change.

13. Business Basic, Standard and Premium licences (and Enterprise)

In practice: migration is an opportunity to align Microsoft 365 licences with the current reality of the organisation.

The CTUDM add-on is independent of the plan. After the migration, you need to choose the licence that best balances cost, security and productivity for each user profile. Many Microsoft 365 tenant-to-tenant migrations are used to rationalise licences and align the model with the current business reality.

It is not necessary for the whole organisation to use the same plan. Combining different licences (for example, Business Premium for critical roles and Business Basic for occasional users) allows cost optimisation without sacrificing security where it matters most.

We recommend reviewing the official plan comparison tables regularly for details and changes.

14. Performance, concurrency and scalability

In practice: performance determines whether the migration progresses at the expected pace without overloading either the platform or the support team.

Respecting service limits, planning off-peak windows and monitoring batch health prevents bottlenecks and surprises during cutover. In a Microsoft 365 tenant-to-tenant migration, performance depends not only on mailbox size but also on available bandwidth, latency and the number of parallel processes.

• Mailbox concurrency: define batch size and percentage per wave (for example, 10–20% of the workforce per window).
• Throttling and windows: align execution with service limits and work in off-peak hours to reduce impact.
• Retries and errors: review Get-MigrationUserStatistics and plan granular re-runs.

It is useful to agree early what an acceptable migration time is and which scenarios would justify moving users to another window. This helps to make quick decisions if any performance degradation is detected during the process.

15. Migration methods and tools (native vs third-party)

In practice: there is no single perfect tool; you choose a combination based on scope, risk and timelines.

Choose your tools based on scope and risk, not just cost. The native path is usually the first option; you can complement it with third-party tools or scripts when the scenario requires it. Each organisation has a different balance between flexibility, official support and time available for automation.

In large projects, the usual pattern is a combination: native approach for most mailboxes and OneDrive, some third-party tool for special cases (for example, very strict compliance or complex consolidations) and custom scripts for repetitive tasks that are worth standardising.

16. Operational checklists (pre, during, post)

In practice: checklists turn the migration into a repeatable process and make it easier for new team members to onboard without losing context.

Clear checklists reduce error margins and make the process repeatable across waves and regions. They also serve as a guide for new team members or partners joining the project.

16.1 Before migration

• CTUDM purchased and assigned to users that will be migrated.
• Cross-tenant access and synchronisation (if applicable) configured.
• Organisation relationships (Free/Busy) created.
• Target users/licences and OneDrive provisioned.
• Communication and support plan per wave.
• Backups/snapshots and rollback plans documented.
• Formal business approval for cutover schedule.

16.2 During migration

• Monitor batches; handle errors and retries.
• Resolve conflicts (delegations, rules, aliases).
• Run incremental syncs until cutover.
• Provide periodic updates to business on the progress of each wave.

16.3 After migration

• Update MX/SPF/DKIM/DMARC and validate delivery.
• Review permissions in SharePoint/OneDrive; recertify access.
• Disable legacy POP/IMAP and close temporary gaps.
• Collect user feedback and refine documentation and FAQs.

17. KPIs, UAT and business acceptance

In practice: defining KPIs and UAT from the beginning helps the business see the migration as a controlled project, not as a risk.

What is not measured cannot be improved. Defining KPIs before the first wave and aligning with business stakeholders on what “success” means at each milestone helps position the migration as a controlled, results-oriented project, not just a set of technical tasks.

User acceptance testing (UAT) should focus on real scenarios: how a customer request is handled, how an incident is managed, how an international project is coordinated, etc. The closer tests are to everyday work, the more valuable the validation will be.

18. Common risks and mitigations

In practice: anticipating risks lets you decide what you absolutely want to avoid and what you can accept with a contingency plan.

Anticipating risks gives you room to manoeuvre. Defining preventive measures and simple, rehearsed contingency plans helps your migration be perceived as a robust process, even when unexpected issues arise.

19. Useful scripts and snippets (PowerShell/JSON) for tenant-to-tenant migrations

In practice: scripts don’t replace design, but they save many hours on repetitive tasks.

These examples help standardise recurring tasks and monitor progress during tenant-to-tenant migrations. They do not replace planning, but they do reduce the time required for repetitive actions.

Connect-ExchangeOnline
Get-MigrationBatch | Select-Object Name,Status,TotalCount,InitialSyncCompleteTime
Get-MigrationUser | Get-MigrationUserStatistics -IncludeReport | `
  Select-Object Identity,ItemsTransferred,PercentComplete,ErrorSummary

Get-CASMailbox -ResultSize Unlimited | Set-CASMailbox -ImapEnabled:$false -PopEnabled:$false

{
  "displayName": "MFA for modern apps",
  "conditions": {
    "users": { "includeUsers": ["All"] },
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": { "operator": "OR", "builtInControls": ["mfa"] }
}

EmailAddress
ana.perez@company.com
john.smith@company.com

20. Frequently asked questions (extended FAQ) about Microsoft 365 tenant-to-tenant migration

21. Official resources and external links for Microsoft 365 tenant-to-tenant migration

• Cross-tenant mailbox migration
• Cross-tenant OneDrive migration
• Cross-tenant SharePoint migration
• Entra ID — Cross-tenant access
• Entra ID — Cross-tenant synchronization
• Remove a domain from a tenant · Add a domain · Create DNS records
• Defender for Office 365
• Microsoft Information Protection (Purview)
• Microsoft Intune
• FastTrack — Cross-tenant migration
• Microsoft 365 plan comparison

You can also explore related MSAdvance services: Microsoft 365 migration, Azure architecture, modern workplace and the full catalogue at services.

22. Conclusion and next steps in a Microsoft 365 tenant-to-tenant migration

A Microsoft 365 tenant-to-tenant migration without data loss rests on four pillars: an honest assessment, well-designed coexistence, CTUDM licences procured in time and a carefully rehearsed domain cutover. With meaningful pilots, measurable waves and security governance from day one, go-live becomes predictable and adoption flows.

As next steps, it is usually useful to:

• Turn this guide into your own checklist, adapted to your business language and reality.
• Define a scoped but representative pilot (one or two key departments).
• Establish a communication and training plan to accompany each wave.

Why rely on a specialised partner for tenant-to-tenant migrations

A specialised Office 365 tenant-to-tenant migration partner brings prior M&A experience, up-to-date knowledge of Microsoft native capabilities and the ability to coordinate IT, security, legal and business teams. This translates into less risk, less improvisation and more internal focus on day-to-day operations.

• Experience in complex scenarios (international mergers, regulated environments, multiple legacy tenants).
• Templates, scripts and checklists already proven in other projects.
• Cross-cutting view of security, compliance and change management.