01
Discover
Inventory tenants, stakeholders, workloads, identities, domains, dependencies, and business priorities.
Microsoft 365 migration
Microsoft 365 Tenant-to-Tenant Migration
Plan and execute tenant migrations with structured discovery, identity mapping, SharePoint and OneDrive migration planning, dependency analysis, validation, and post-migration support.
SOURCE TENANT
Entra IDSharePointOneDriveTeamsMicrosoft 365 GroupsPower PlatformBusiness Applications
TARGET TENANT
Entra IDSharePointOneDriveTeamsMicrosoft 365 GroupsPower PlatformBusiness Applications
Discover
Map
Plan
Migrate
Validate
Workloads may require different migration mechanisms, tooling, permissions, and validation methods.
Why Tenant Migrations Happen
Tenant migration usually follows a business event. The technical plan needs to respect ownership, identity, collaboration, governance, and application continuity.
Mergers & acquisitions
Divestitures
Tenant consolidation
Business separation
Corporate rebranding
Domain consolidation
Organizational restructuring
Microsoft 365 architecture changes
Not just data transfer
Tenant Migration Is a Relationship Mapping Problem
Successful tenant migration requires understanding relationships between users, groups, SharePoint sites, OneDrive accounts, Teams, applications, permissions, external users, and business processes.
Identity
Content
Permissions
Collaboration
Applications
Dependencies
Domains
Business Processes
Output
Tenant Migration Strategy
Discovery & assessment
Assess the Source Tenant Before Migration
Discovery should inspect available tenant information, workload relationships, and migration risks where access and tooling permit. It should not claim visibility into systems where appropriate access is unavailable.
Users
Entra ID identities
Guest users
Security groups
Microsoft 365 Groups
Domains
SharePoint sites
Hub sites
SharePoint storage
OneDrive accounts
Microsoft Teams
Permissions
External sharing
Power Apps
Power Automate
Dataverse
SPFx solutions
Enterprise applications
Third-party integrations
Custom APIs
Microsoft Graph integrations
Business-critical dependencies
Identity Mapping
Identity planning is foundational to workload migration. Simply copying data does not automatically preserve every user, group, owner, guest, permission, or application relationship.
SOURCE IDENTITY
user@companyA.com
Identity Mapping
TARGET IDENTITY
user@companyB.com
User mapping
UPN changes
Domain changes
Group mapping
Guest identities
External sharing
Permission references
Ownership
Application dependencies
Authentication dependencies
SharePoint Tenant-to-Tenant Migration
SharePoint migration planning should cover site mapping, content structure, permissions, metadata, sharing, pages, SPFx dependencies, Power Platform dependencies, and tenant-specific integrations.
SOURCE SHAREPOINT
Site Mapping
Migration
Validation
TARGET SHAREPOINT
Unsupported or tenant-specific dependencies should be identified before migration.
Site inventory
Site mapping
Hub associations
Libraries
Lists
Files
Folders
Metadata
Content types
Versions
Permissions
External users
Sharing links where applicable
Modern pages
SPFx dependencies
Power Platform dependencies
Custom integrations
OneDrive Migration
OneDrive migration should be planned around user mapping, target readiness, ownership, content scope, sharing behavior, and validation. Existing sharing links and permissions should not be promised universally.
Source User
Identity Mapping
Source OneDrive
Migration
Target OneDrive
Validation
User-to-user mapping
OneDrive inventory
Content migration
Permissions and sharing considerations
Ownership
Target user readiness
Validation
Microsoft Teams Scope
Teams migration can involve multiple Microsoft 365 services and dependencies. Supported scope and fidelity depend on migration tooling, workload shape, tenant configuration, and project requirements.
Teams
Channels
Membership
Microsoft 365 Groups
SharePoint-connected content
Files
Tabs
Apps
External users
Power Platform dependencies
Third-party integrations
Microsoft 365 Groups
Group mapping matters before workload migration because ownership, membership, connected sites, Teams relationships, permissions, and naming all influence target readiness.
Group ownership
Membership
SharePoint-connected sites
Teams relationships
Permissions
Naming
Target tenant mapping
Tenant Migration + Power Platform Dependencies
Power Platform workloads should not be assumed to migrate automatically with SharePoint content. They require separate assessment and migration or remediation planning.
Power Apps
Power Automate
Dataverse
Connections
Connection references
Environment variables
Custom connectors
Service accounts
SharePoint dependencies
Teams dependencies
Entra ID dependencies
Environment strategy
SPFx & custom solutions
Custom Solutions Need Dependency Review
SPFx packages and custom integrations often include tenant-specific URLs, IDs, API permissions, app catalog deployment, endpoints, and configuration that require remediation before target deployment.
Existing SPFx Solution
Dependency Review
Configuration Remediation
Target Deployment
Validation
SPFx packages
App Catalog
Tenant-wide deployment
API permissions
Microsoft Graph permissions
Custom APIs
External endpoints
Environment-specific configuration
Tenant-specific URLs
Hard-coded IDs
SharePoint site dependencies
Domain & URL Changes
URL and domain dependencies should be identified during assessment so hard-coded links, application references, flows, apps, SPFx solutions, APIs, and integrations do not surprise the cutover.
Domain changes
User principal names
Email addresses
SharePoint URLs
OneDrive URLs
Hard-coded links
Bookmarks
Custom applications
Power Automate flows
Power Apps
SPFx
APIs
External integrations
Migration Methodology
02
Assess
Review migration readiness, access, customizations, workload constraints, risks, and scope boundaries.
03
Map
Map users, groups, domains, sites, OneDrive accounts, owners, permissions, and target destinations.
04
Design
Create target architecture, wave plan, tooling approach, cutover model, and validation strategy.
05
Remediate
Fix blockers, clean up identities, prepare target structures, and address dependency risks.
06
Pilot
Test representative users, sites, OneDrive accounts, permissions, reports, and business processes.
07
Migrate
Execute agreed migration waves using appropriate native, third-party, or custom tooling.
08
Validate
Compare source and target results, migration reports, permissions, ownership, and user acceptance.
09
Cut Over
Coordinate communications, supported delta moves, DNS/domain activities, readiness, and support.
10
Support
Stabilize users, remediate exceptions, review governance, and plan modernization opportunities.
Illustrative sequence
Migration Waves
Actual sequencing depends on business dependencies and workload scope. Waves help reduce risk by separating pilots, low-risk workloads, standard business content, and complex cutover work.
Wave 0
Discovery & Assessment
Wave 1
Pilot Users / Sites
Wave 2
Low-Risk Workloads
Wave 3
Standard Business Workloads
Wave 4
Complex / Business-Critical Workloads
Final Cutover
Business transition
Post-Migration Validation
Reconcile, remediate, support
Migration Tooling
Tooling depends on workloads and requirements. A single tool should not be assumed to handle every Microsoft 365 workload, fidelity expectation, dependency, or validation requirement.
Microsoft native migration capabilities
Microsoft cross-tenant migration capabilities where applicable
ShareGate
PnP PowerShell
PowerShell
Microsoft Graph
Migration APIs
Specialized third-party migration tools where appropriate
Custom validation tooling
Migration validation
Migration Completion Does Not Automatically Mean Business Readiness
Validation should compare source and target where applicable. Migration reports are useful, but user acceptance, business process checks, ownership, permissions, and dependency testing matter too. Perfect fidelity should not be guaranteed.
Migration reportsFailed/skipped itemsContent reconciliationMetadata validationPermission validationIdentity mapping validationOwnership validationVersion validationApplication testingBusiness-process testingUser acceptance testing
Source TenantTarget Tenant
UsersUsers
GroupsGroups
SitesSites
LibrariesLibraries
FilesFiles
MetadataMetadata
VersionsVersions
PermissionsPermissions
OneDriveOneDrive
DependenciesDependencies
M&A / Divestiture Scenario Examples
Merger / Acquisition
COMPANY A TENANT + COMPANY B TENANT
Discovery & Mapping
Identity + Content + Collaboration + Applications
TARGET MICROSOFT 365 TENANT
Divestiture
PARENT TENANT
Identify Business Unit
Users + SharePoint + OneDrive + Teams + Dependencies
NEW / TARGET TENANT
These are illustrative architectures only. Actual design depends on business scope, identity model, workloads, tooling, and access.
Cutover Planning
Cutover should be planned around the real business transition. No tenant migration should promise zero downtime without a validated technical and business basis.
Migration waves
Change freeze where appropriate
Delta/incremental migration where supported
User communication
DNS/domain considerations where applicable
Business application readiness
Permissions
Validation
Support
Rollback/contingency planning where technically possible
After migration
Stabilize, Then Modernize
Post-migration work turns a completed move into a usable operating state, then creates room for governance and modernization.
Migrate
Validate
Stabilize
Modernize
Govern
Validation
Permission remediation
Broken-link remediation
SPFx configuration
Power Platform remediation
User support
Governance
Sharing review
Legacy tenant cleanup planning
Modernization opportunities
Service Scope Transparency
Some workloads require separate tooling, specialist implementation, or coordinated delivery. Exchange Online, Intune, endpoint management, complex Entra ID scenarios, third-party SaaS, telephony, and compliance workloads should be treated as assessment, dependency planning, migration coordination, or integration considerations unless a specific delivery scope is agreed.
Who This Service Is For
Organizations merging Microsoft 365 tenants
Organizations acquiring another company
Organizations separating a business unit
Organizations consolidating multiple tenants
Organizations changing corporate domains
Organizations restructuring Microsoft 365 environments
Organizations moving SharePoint/OneDrive content between tenants
Organizations dealing with complex Microsoft 365 dependencies
Organizations needing migration validation
Tenant migration assessment
Before Moving Data, Map the Tenant.
Start with users, groups, content, collaboration spaces, permissions, Power Platform, SPFx, applications, and dependencies before setting migration waves.
Users
Groups
SharePoint
OneDrive
Teams
Permissions
Power Platform
SPFx
Applications
Tenant Migration Assessment
Migration Roadmap
Tenant migration enquiry
Discuss Your Tenant Migration
Share the migration scenario, workloads, rough scale, timeline, and key challenges. Do not submit passwords, credentials, tenant secrets, or sensitive Microsoft 365 information through this form.
Related Microsoft 365 Migration Resources
Frequently Asked Questions
What is a Microsoft 365 tenant-to-tenant migration?
It is the planned movement or reconfiguration of Microsoft 365 users, content, collaboration spaces, permissions, domains, and dependencies from one tenant context to another. The exact scope depends on the workloads involved.
When is tenant migration required?
Tenant migration is common during mergers, acquisitions, divestitures, consolidations, business separations, domain changes, and Microsoft 365 architecture changes.
How do mergers and acquisitions affect Microsoft 365 tenants?
M&A work often requires identity mapping, domain planning, SharePoint and OneDrive migration planning, collaboration decisions, application dependency review, and a careful cutover plan.
Can SharePoint sites move between Microsoft 365 tenants?
SharePoint content can often be migrated between tenants, but site structure, permissions, metadata, versions, pages, sharing, SPFx, and integrations must be assessed and validated.
Can OneDrive content move between tenants?
OneDrive migration usually depends on user-to-user mapping, target account readiness, content scope, permissions, sharing behavior, and the selected migration tooling.
What happens to permissions during tenant migration?
Permissions need mapping and validation. Copying content alone does not guarantee every user, group, external guest, ownership, or sharing relationship remains equivalent.
What happens to external users?
External users and sharing relationships should be discovered and planned carefully because guest identities, invites, permissions, and collaboration patterns may change between tenants.
Can Microsoft Teams be migrated?
Teams migration can involve groups, channels, memberships, files, tabs, apps, and connected services. Supported fidelity depends on tooling, tenant configuration, workload scope, and project requirements.
What happens to Power Apps and Power Automate?
Power Platform workloads should not be assumed to move automatically with SharePoint content. Apps, flows, connections, connection references, environment variables, and Dataverse dependencies need separate assessment and planning.
What happens to SPFx solutions?
SPFx solutions may require app catalog deployment, API permission review, target configuration, URL and ID remediation, and validation. They cannot always be copied between tenants without changes.
Do SharePoint URLs change?
Tenant, domain, site, and OneDrive URL changes are common in tenant migrations and should be assessed for hard-coded links, apps, flows, SPFx, APIs, bookmarks, and integrations.
How are users mapped between tenants?
Users are mapped from source identities to target identities using UPN, domain, ownership, group, permission, and application dependency planning. Identity mapping is foundational to workload migration.
Which migration tools should be used?
Tooling depends on workload scope, source and target configuration, reporting needs, supported fidelity, timeline, and validation requirements. No single tool handles every Microsoft 365 workload universally.
How do you validate a tenant migration?
Validation should compare source and target users, groups, sites, libraries, files, metadata, versions, permissions, OneDrive accounts, dependencies, reports, and business-process outcomes where applicable.
How long does a Microsoft 365 tenant migration take?
Timeline depends on user count, data volume, workload scope, dependency complexity, tooling, access, remediation, migration windows, validation depth, and business cutover requirements.