Tools, Scripts, and Ways to Migrate Between Microsoft 365 Tenants: Complete Guide to Choosing the Best Approach

Quick summary: how to choose tools to migrate between Microsoft 365 tenants

1. There is no single perfect tool: Exchange, OneDrive, SharePoint, Teams, Planner, Power Platform, and identity each have different limits and methods.
2. Exchange Online has a solid native path: cross-tenant mailbox migration relies on Exchange Online PowerShell, batches, and tenant-to-tenant prerequisites.
3. OneDrive and SharePoint have cross-tenant capabilities: useful for moving content, but they require planning, compatibility checks, user mapping, and permission validation.
4. Teams is more delicate: files, channels, members, tabs, meetings, chats, and apps do not behave the same way; many migrations require third-party tools or controlled reconstruction.
5. Entra ID is the foundation of coexistence: cross-tenant access, B2B, and cross-tenant synchronization help users collaborate while the migration progresses.
6. Scripts are essential: inventory, mapping, validation, reporting, and retries are usually automated with PowerShell, Microsoft Graph, and administration modules.
7. Third-party tools provide speed and traceability: ShareGate, Quest, BitTitan, Cloudiway, AvePoint, and other solutions can reduce manual work and improve reporting.
8. Performance does not depend only on the tool: mailbox size, number of files, throttling, working windows, network, permissions, retention, and tenant health all matter.
9. Coexistence prevents disruption: mail, calendars, external collaboration, and domains must be designed before the first migration batch.
10. Success is measured by users being able to work: moving data is not enough; Outlook, Teams, OneDrive, permissions, meetings, mobile devices, and support must be validated.

When do you need a migration between Microsoft 365 tenants?

A migration between Microsoft 365 tenants is usually needed when an organization has to consolidate, separate, or reorganize environments. It may be triggered by a merger, an acquisition, a carve-out, a corporate domain change, or a governance decision to reduce several legacy tenants into a single one.

Common scenarios

• Mergers and acquisitions: two organizations are integrated and want to unify email, files, Teams, security, and domains.
• Carve-out or business separation: a business unit becomes independent and needs its own tenant with users, data, and permissions.
• Tenant consolidation: companies with several legacy tenants want to reduce complexity, licensing overhead, and administration effort.
• Rebranding or domain change: the primary domain changes and the organization uses the opportunity to reorganize identities and services.
• Partner or architecture change: Microsoft 365, Entra ID, security, and collaboration are redesigned from a cleaner foundation.
• Security and compliance unification: the organization wants to apply a common policy for MFA, Conditional Access, Purview, Defender, and retention.

Introduction: why a tenant-to-tenant migration is more than copying data

Microsoft 365 is not a single application. It is an ecosystem made up of identity, email, files, collaboration, security, compliance, devices, and automations. That is why an Office 365 tenant-to-tenant migration requires understanding dependencies: a Teams team has a Microsoft 365 group, a SharePoint site, members, owners, files, tabs, meetings, and permissions. A user has a mailbox, OneDrive, MFA, devices, groups, applications, and permissions over shared data.

The tool you choose matters, but it does not replace design. A third-party platform can significantly accelerate the work, but without a good map of users, permissions, domains, and workloads, it will also migrate disorder. In the same way, a native migration can be very robust, but it requires more scripting, coordination, and validation.

The key is choosing wisely: native capabilities when they provide stability and control, third-party platforms when traceability and speed are needed, and scripts when repetitive tasks should be automated. In real projects, the most common answer is a combination.

1. Ways to migrate between Microsoft 365 tenants

In practice: there are four approaches: native, third-party, hybrid, or controlled reconstruction. The choice depends on scope, risk, and available time.

Big bang vs wave-based migration

A single cutover may look simpler, but it increases risk. In environments with many users, multiple countries, critical data, or strong email dependency, the most sensible option is usually to work in waves: pilot, first controlled wave, department-based waves, and final domain cutover.

• Big bang: less coexistence time, more pressure during cutover.
• Waves: more control, more learning, better user support.
• Hybrid: data is pre-staged in waves, but the domain is moved in a single window.

2. Microsoft native tools by workload

In practice: native capabilities are the first option to review, but they do not always cover the entire project.

3. Third-party tools: comparison and when to use them

In practice: third-party tools are not “better” by default, but they help significantly when there is volume, time pressure, or reporting requirements.

ShareGate

ShareGate is often a very good fit when the migration has a strong focus on SharePoint Online, Teams, and OneDrive. Its value is not only in moving content, but also in understanding it: detecting broken permissions, inactive sites, very large libraries, missing owners, and structures that should be redesigned before being copied.

• Strengths: pre-migration analysis, permission mapping, clear reports, and a good experience for IT teams.
• Limitations: it is not the main tool for Exchange mailbox migrations.
• When to use it: intranets, departmental sites, Teams with a lot of documentation, and migrations where cleanup is a priority.

Quest On Demand Migration

Quest On Demand Migration is commonly seen in large programs, especially mergers and acquisitions. It provides a project-level view: users, waves, workload progress, coexistence, incidents, and executive reporting. It is useful when several stakeholders need to see status and risks without going into PowerShell commands.

• Strengths: broad coverage, dashboards, wave planning, reporting, and coexistence.
• Limitations: it requires budget and careful configuration.
• When to use it: medium or large projects with many workloads, executive involvement, and traceability requirements.

BitTitan MigrationWiz

MigrationWiz is known for its fast setup and for being a SaaS platform strongly oriented toward execution. It can be a good option when the goal is to move email or documents with a clear model, without deploying your own infrastructure, and with a reasonable learning curve.

• Strengths: speed, simplicity, automation, and cloud-to-cloud projects.
• Limitations: it is not always the best option for deep SharePoint or Teams redesign.
• When to use it: projects with a defined scope, tight timelines, and a focus on email/documents.

Cloudiway

Cloudiway stands out when the migration is not only Microsoft 365 to Microsoft 365. If Google Workspace, Slack, Box, or other sources are involved, a multi-suite platform can save a lot of integration and mapping effort.

• Strengths: heterogeneous connectors, multi-platform scenarios, and flexibility.
• Limitations: it requires more mapping design and testing.
• When to use it: mergers with different suites, migrations from Google or Slack, and projects with complex coexistence.

4. Decision matrix: native, third-party, or hybrid approach

In practice: the right method is the one that reduces risk and total cost, not necessarily the one that looks cheaper at the beginning.

5. Pre-migration assessment: inventory, dependencies, and mappings

In practice: the better the inventory, the fewer surprises appear during cutover.

Before choosing a tool, you need to know what will be moved. It sounds obvious, but many migrations start with incomplete data: users who no longer exist, shared mailboxes without an owner, sites without an owner, abandoned Teams, old transport rules, forgotten connectors, or critical automations that depend on a personal account.

Essential mappings

• Source user → target user.
• Source UPN → target UPN.
• Source SMTP → target SMTP.
• Source OneDrive → target OneDrive.
• Source SharePoint site → target site.
• Source Teams team → target team or reconstruction.
• Source group → target group.

6. Useful PowerShell scripts for tenant-to-tenant migrations

In practice: scripts do not replace the migration tool, but they make the project repeatable, auditable, and safer.

The following examples are guidance templates. They must be adapted to each tenant, permissions, current modules, naming conventions, authentication strategy, and organizational security policies.

6.1 User inventory with Microsoft Graph PowerShell

Connect-MgGraph -Scopes "User.Read.All","Group.Read.All","Directory.Read.All"

Get-MgUser -All -Property Id,DisplayName,UserPrincipalName,Mail,AccountEnabled |
  Select-Object Id,DisplayName,UserPrincipalName,Mail,AccountEnabled |
  Export-Csv ".\user-inventory.csv" -NoTypeInformation -Encoding UTF8

Get-MgGroup -All -Property Id,DisplayName,Mail,MailEnabled,SecurityEnabled |
  Select-Object Id,DisplayName,Mail,MailEnabled,SecurityEnabled |
  Export-Csv ".\group-inventory.csv" -NoTypeInformation -Encoding UTF8

6.2 Basic Exchange Online inventory

Connect-ExchangeOnline

Get-EXOMailbox -ResultSize Unlimited |
  Select-Object DisplayName,UserPrincipalName,PrimarySmtpAddress,RecipientTypeDetails |
  Export-Csv ".\mailbox-inventory.csv" -NoTypeInformation -Encoding UTF8

Get-DistributionGroup -ResultSize Unlimited |
  Select-Object DisplayName,PrimarySmtpAddress,ManagedBy |
  Export-Csv ".\distribution-groups-inventory.csv" -NoTypeInformation -Encoding UTF8

Get-Mailbox -ResultSize Unlimited |
  Get-MailboxPermission |
  Where-Object { $_.User -notlike "NT AUTHORITY\SELF" } |
  Export-Csv ".\mailbox-permissions.csv" -NoTypeInformation -Encoding UTF8

6.3 Exchange migration batch tracking

Connect-ExchangeOnline

Get-MigrationBatch |
  Select-Object Identity,Status,TotalCount,ActiveCount,StoppedCount,FailedCount |
  Format-Table -AutoSize

Get-MigrationUser -ResultSize Unlimited |
  Get-MigrationUserStatistics -IncludeReport |
  Select-Object Identity,Status,PercentComplete,ItemsTransferred,BytesTransferred,ErrorSummary |
  Export-Csv ".\exchange-migration-status.csv" -NoTypeInformation -Encoding UTF8

6.4 OneDrive and SharePoint inventory

Connect-SPOService -Url "https://contoso-admin.sharepoint.com"

Get-SPOSite -Limit All -IncludePersonalSite $true |
  Select-Object Url,Owner,Template,StorageUsageCurrent,LastContentModifiedDate |
  Export-Csv ".\sharepoint-onedrive-inventory.csv" -NoTypeInformation -Encoding UTF8

6.5 Teams and member inventory

Connect-MicrosoftTeams

$teams = Get-Team
$teams | Select-Object GroupId,DisplayName,Visibility,Archived |
  Export-Csv ".\teams-inventory.csv" -NoTypeInformation -Encoding UTF8

foreach ($team in $teams) {
  Get-TeamUser -GroupId $team.GroupId |
    Select-Object @{Name="Team";Expression={$team.DisplayName}},User,Role |
    Export-Csv ".\teams-members.csv" -Append -NoTypeInformation -Encoding UTF8
}

6.6 Detecting Teams with too few owners

Connect-MicrosoftTeams

$report = foreach ($team in Get-Team) {
  $owners = Get-TeamUser -GroupId $team.GroupId -Role Owner
  [PSCustomObject]@{
    TeamName = $team.DisplayName
    GroupId = $team.GroupId
    Owners = ($owners.User -join ";")
    OwnerCount = $owners.Count
  }
}

$report | Where-Object { $_.OwnerCount -lt 2 } |
  Export-Csv ".\teams-with-few-owners.csv" -NoTypeInformation -Encoding UTF8

6.7 Mapping CSV template

SourceUPN,TargetUPN,SourcePrimarySmtp,TargetPrimarySmtp,Wave,Department
ana.perez@source.com,ana.perez@target.com,ana.perez@source.com,ana.perez@target.com,Wave-01,Finance
juan.garcia@source.com,juan.garcia@target.com,juan.garcia@source.com,juan.garcia@target.com,Wave-01,Operations

7. Automation, logging, and error control

In practice: automation does not mean “launching scripts without supervision”; it means repeating safely, with logs, validations, and checkpoints.

Automation best practices

• Separate scripts by function: inventory, preparation, validation, execution, reporting, and rollback.
• Use structured logging: CSV, JSON, or Log Analytics to review errors by user and workload.
• Implement retries: especially for throttling, 429/503 errors, or temporary responses.
• Control parallelism: too many parallel tasks can make performance worse.
• Protect secrets: no plain-text passwords; use vaults, managed identities, or certificates whenever possible.
• Version scripts: Git allows you to know what changed, when, and why.
• Validate before and after: execution is not enough; the result must be checked.

Example Try/Catch pattern with logging

$log = ".\migration-log.csv"

function Write-MigrationLog {
  param(
    [string]$ObjectId,
    [string]$Action,
    [string]$Status,
    [string]$Message
  )

  [PSCustomObject]@{
    Timestamp = (Get-Date).ToString("s")
    ObjectId  = $ObjectId
    Action    = $Action
    Status    = $Status
    Message   = $Message
  } | Export-Csv $log -Append -NoTypeInformation -Encoding UTF8
}

foreach ($item in Import-Csv ".\mapping.csv") {
  try {
    # Example action
    Write-Host "Processing $($item.SourceUPN)"
    Write-MigrationLog -ObjectId $item.SourceUPN -Action "PreCheck" -Status "OK" -Message "Validation completed"
  }
  catch {
    Write-MigrationLog -ObjectId $item.SourceUPN -Action "PreCheck" -Status "ERROR" -Message $_.Exception.Message
  }
}

8. Coexistence: email, calendars, Teams, and identity

In practice: coexistence allows the company to keep working while the migration progresses.

8.1 Email coexistence

In wave-based migrations, some users may be in the source tenant while others are already in the target tenant. You need to design how email is delivered, how aliases are resolved, how internal messages are routed, and when the primary domain will be moved.

• Temporary connectors and transport rules.
• Contacts or mail users to represent users from the other tenant.
• Temporary forwarding by wave when necessary.
• Validation of SPF, DKIM, and DMARC in the target domain.
• A clear plan to move MX and Autodiscover.

8.2 Calendar coexistence

Free/busy availability is critical for sales, leadership, support, and project teams. If users are split across tenants, it is advisable to prepare organization relationships or alternative visibility options before starting large waves.

8.3 Teams coexistence

Teams requires special care: chats, channels, meetings, guests, files, tabs, and permissions do not depend on a single layer. During coexistence, B2B, external access, shared channels, and federation rules can be used, but it must be clearly defined where people work: source tenant, target tenant, or both for a limited period.

8.4 Domain move

The corporate domain cannot remain active as the primary accepted domain in two tenants indefinitely. The move must be rehearsed: clean references in the source, prepare the target, reduce TTL when applicable, change DNS, and validate delivery.

9. Identity and directory: Entra ID cross-tenant

In practice: if identity is not properly designed, everything else becomes more complicated.

Microsoft Entra ID provides several capabilities for collaboration and coexistence between organizations: cross-tenant access, B2B collaboration, B2B direct connect, and cross-tenant synchronization. In a migration, these components help users access resources before all data has been moved.

What to decide before configuring identity

• Temporary UPN and final UPN.
• Primary email domain during each phase.
• Guest users vs member users.
• Groups that will be replicated or rebuilt.
• Administrative roles in the target tenant.
• MFA and Conditional Access policies.
• Enterprise applications and SSO.

Cross-tenant synchronization

Cross-tenant synchronization can help create, update, and remove B2B users in a target tenant. It does not replace data migration, but it makes permissions, collaboration, and gradual access easier.

10. Exchange Online: options, scripts, and best practices

In practice: Exchange is usually the most visible workload. If email fails, users perceive the entire migration as failed.

Common options

• Cross-tenant mailbox migration: native path to move mailboxes between tenants when requirements are met.
• Third-party tools: useful for reporting, advanced coexistence, or non-standard scenarios.
• PST: residual option for specific cases, historical data, or special users.

Best practices

• Work in batches and do not mix critical users with massive waves.
• Prepare target users before starting migrations.
• Validate shared mailboxes, permissions, delegations, and calendars.
• Review transport rules and connectors.
• Tell users what changes in Outlook and mobile devices.
• Measure mailbox size, corrupt items, online archive, and retention.

Post-migration validations

• Internal and external sending and receiving.
• Access through Outlook and Outlook on the web.
• Calendar and existing meetings.
• Delegated permissions and shared mailboxes.
• Archiving, retention, and eDiscovery.

11. OneDrive and SharePoint: cross-tenant migration and reorganization

In practice: the challenge is not only moving files, but preserving context, permissions, and a useful structure.

OneDrive

OneDrive often contains personal work information: work-in-progress documents, drafts, files shared with colleagues, and links sent to external users. The migration must manage expectations: some links will need to be recreated and certain permissions do not translate exactly.

SharePoint

SharePoint is more complex because it often contains departmental sites, intranets, libraries with metadata, modern pages, lists, inherited permissions, automations, forms, Teams tabs, and external links. Here, it is important to decide whether to migrate as-is or use the opportunity to organize the environment.

Best practices

• Inventory sites, size, owners, activity, and permissions.
• Archive inactive sites before migrating.
• Review libraries with too many versions.
• Map users and groups before moving content.
• Test with representative sites: one simple, one large, and one complex.
• Validate navigation, pages, permissions, and links after migration.

12. Microsoft Teams: what can be moved and what should be rebuilt

In practice: Teams is a collaboration layer, not an isolated repository. That is why it usually requires a more careful approach.

Many components coexist in Teams: Microsoft 365 group, SharePoint site, channels, members, owners, files, messages, tabs, apps, bots, meetings, recordings, and permissions. Some components can be migrated, others are recreated, and others should be redesigned.

What to review in Teams

• Active, archived, and inactive teams.
• Owners and members.
• Standard, private, and shared channels.
• Files associated with channels.
• Tabs: Planner, OneNote, SharePoint, Power BI, third-party apps.
• Recurring meetings and recordings.
• Guests and external users.

Common approaches

• Recreate structure: new teams and channels with migrated files.
• Migrate with third-party tools: when more context needs to be preserved and execution accelerated.
• Rebuild with governance: use the opportunity to remove duplicate teams and create a cleaner structure.

13. Planner, Bookings, Stream, and other workloads

In practice: “small” workloads can generate many incidents if nobody reviews them.

Planner

Planner is often associated with Teams. When migrating a team, it is important to review plans, buckets, tasks, attachments, assignees, and dates. In many cases, it is recreated or moved with a third-party tool.

Bookings

Bookings may depend on mailboxes, calendars, users, and services. If there are customer appointments or integrations, it must be reviewed before cutover.

Stream on SharePoint

Videos stored in SharePoint or OneDrive should be treated as files, but with additional attention: embedded links, permissions, Teams tabs, and pages where videos are embedded.

Lists, Forms, OneNote, and Whiteboard

These workloads usually require individual review. Some can be exported, others are recreated, and others depend on the team or site they are linked to.

14. Power Platform, Power BI, and connected applications

In practice: a migration can “break” automations even if email and files work perfectly.

Power Automate, Power Apps, Power BI, Dataverse, and connectors often depend on users, permissions, URLs, SharePoint lists, mailboxes, credentials, and registered applications. If they are not inventoried, errors appear after cutover.

What to inventory

• Critical Power Automate flows.
• Power Apps used by the business.
• Connections and credentials.
• Power Platform environments.
• Dataverse tables and dependencies.
• Power BI workspaces, datasets, and gateways.
• Applications registered in Entra ID.

Recommended strategy

• Classify automations by criticality.
• Export solutions whenever possible.
• Recreate connections with controlled service accounts.
• Test flows end-to-end with business users.
• Document owners and support for each automation.

15. Performance, throttling, and scalability

In practice: more speed does not always mean more parallelism. Sometimes launching too many tasks makes the result worse.

Microsoft 365 protects its services through throttling mechanisms. This means that if a migration makes too many requests, the service may respond with temporary limits. The solution is not to retry without control, but to respect headers such as Retry-After, reduce concurrency, and plan working windows.

Factors that affect performance

• Mailbox size and number of items.
• Number of small files in OneDrive/SharePoint.
• Document versions.
• Unique permissions and inherited structures.
• Network, latency, and geographic location.
• Service peak hours.
• Health of the source and target tenants.
• Tool used and configured concurrency.

Best practices

• Start with a realistic pilot, not an empty user.
• Measure GB/hour, items/hour, and errors per batch.
• Separate VIP or critical users.
• Avoid migrating everything in one giant task.
• Use controlled retries.
• Do not increase agents or threads without measuring impact.

16. Security, compliance, and retention

In practice: migration is an opportunity to improve security, but it can also break compliance if it is not coordinated.

Controls to review

• MFA and Conditional Access.
• Administrative roles and privileged accounts.
• Microsoft Purview: retention, labels, eDiscovery, and DLP.
• Defender for Office 365 and anti-phishing policies.
• External sharing in SharePoint and OneDrive.
• Guests and B2B in Teams.
• Legacy protocols and old applications.

Retention and eDiscovery

Retention policies and legal cases can block moves or require data preservation. Before migrating, it is important to review which information is under retention, what must remain in the source tenant, and what must be recreated in the target tenant.

Related service: Microsoft 365 Security and Compliance.

17. Operational checklists

17.1 Before choosing a tool

• Inventory of users, mailboxes, OneDrive, SharePoint, and Teams.
• Domain and DNS map.
• Application, Power Platform, and connector map.
• Identification of critical users.
• Scope definition: what is migrated, what is archived, what is rebuilt.
• Compliance and retention requirements.

17.2 Before the pilot

• Target users created and licensed.
• Administrative permissions prepared.
• Mappings reviewed.
• Tool configured.
• Scripts tested in read-only mode.
• Communication plan prepared.

17.3 During the waves

• Status tracking by workload.
• Error and retry logging.
• Validation with real users.
• Business communication.
• Incident control and pending decisions.

17.4 After cutover

• Validate email, calendars, Teams, and files.
• Review permissions and external links.
• Confirm DNS and email authentication.
• Review security and compliance.
• Update documentation.
• Plan source tenant retirement.

18. Common risks and how to mitigate them

19. Frequently asked questions about tools for migrating between Microsoft 365 tenants

20. Official resources and external links

Official Microsoft documentation

• Microsoft 365 tenant-to-tenant migrations
• Cross-tenant mailbox migration
• Cross-tenant OneDrive migration
• Cross-tenant SharePoint site migration
• Microsoft Entra cross-tenant access
• Microsoft Entra cross-tenant synchronization
• SharePoint and OneDrive migration performance
• Microsoft Graph throttling guidance
• Power Platform tenant-to-tenant migration

Related MSAdvance services

• Microsoft 365 Tenant-to-Tenant Migration
• Microsoft 365 Migration
• Modern Workplace Microsoft 365
• Microsoft 365 Security and Compliance
• Azure Cloud Architecture
• All services

21. Conclusion and next steps

A well-planned migration between Microsoft 365 tenants does not depend on a single tool. It depends on understanding the environment, choosing the right method for each workload, automating repetitive tasks, controlling risks, and supporting users throughout the change.

The strongest approach usually combines Microsoft native capabilities, specialized tools when they provide value, and PowerShell scripts for inventory, validation, and reporting. This avoids improvisation, reduces disruption, and ensures the new tenant is not a disorganized copy of the old one, but a cleaner, safer, and more governable foundation.