Microsoft 365 Tenant-to-Tenant Migration
MSAdvance plans and delivers Microsoft 365 tenant-to-tenant migrations for organizations that need to move users, email, OneDrive, SharePoint, Teams, identities and domains with a clearly defined scope, a coordinated cutover and full validation of the target environment.
Tenant-to-TenantScope, identities, workloads, domains and cutover are coordinated as one project.
One project to coordinate identity, data, domain and cutover
A Microsoft 365 tenant-to-tenant migration is the process of moving an organization's workloads and services from one tenant to another. MSAdvance turns that objective into an executable project: what will move, which method will be used, in what order, what impact to expect, and how the result will be validated.
The scope can be complete or partial. We can take responsibility for the full project or work only on selected workloads, coordinating with your internal team or other providers where required.
Microsoft 365 specialists for projects where moving data is only part of the job
In a tenant-to-tenant migration, the main risks are usually in the dependencies: identities, permissions, domains, Teams, retention, devices or applications. MSAdvance provides a specialist team that reviews those dependencies before cutover and takes technical responsibility through stabilization of the agreed scope.
When a Microsoft 365 tenant-to-tenant migration makes sense
The business reason drives the architecture, workloads and project sequence. These are the scenarios in which we most often support IT teams and organizations moving from multiple environments to a stable, manageable target state.
Merger or acquisition
Consolidation of two organizations into a common tenant, with temporary coexistence and workload migration in controlled waves.
Carve-out or separation
Controlled separation of a business unit, subsidiary or company, moving only the users, data and services that must leave the source tenant.
Domain change
Reorganization of identities and email with domain release from the source, addition to the target and coordinated DNS updates.
IT consolidation
Reduction of historical tenants, simplified governance and normalization of identity, collaboration and administration.
A real example of a tenant-to-tenant consolidation
In one of our published projects, an organization needed to consolidate two tenants following a merger while keeping services operational and coordinating Exchange Online, OneDrive, SharePoint, Teams, Entra ID and the final domain move.
800 users and approximately 12 TB consolidated into a single tenant
The work was organized around technical discovery, coexistence, pilot, migration waves, domain move and hypercare. The case study also covers real issues involving retention, throttling, Teams and SSO applications, and how they were addressed during the project.
The point is not to repeat these numbers on every project. It is to show that the methodology can scale to environments with significant volume, dependencies and demanding change windows.
What can be migrated between Microsoft 365 tenants and how we approach each workload
The service can include the main Microsoft 365 workloads and related components. For each workload, we define the method, requirements, limitations and acceptance checks before adding it to the migration plan.
Exchange Online
Native option availableUser mailboxes and user-visible mailbox content using cross-tenant mailbox migration when the scenario meets Microsoft requirements.
- Email, contacts, calendar, tasks and notes.
- Preparation of MailUser objects and organization relationships.
- Mail flow, free/busy and coexistence according to the design.
OneDrive
Native option availableCross-tenant OneDrive migration with identity mapping and post-migration redirection where applicable.
- Files, folders and permissions associated with mapped identities.
- The target OneDrive must not already exist.
- The native move is a single-pass operation, with no subsequent delta migration.
SharePoint Online
Native option availableMicrosoft provides cross-tenant SharePoint site migration with specific preparation and licensing requirements.
- Sites and content with mapped permissions.
- Post-migration redirects for migrated content.
- Separate review of integrations, apps, automations and taxonomy.
Microsoft Teams
Mixed approachTeams combines personal and shared data. Microsoft Migration Orchestrator covers chats and meetings, while shared teams and channels fall outside that scope and require a separate approach.
- Chats and meetings: according to the available native capability and service status.
- Teams, channels and files: project-specific strategy.
- Apps, tabs, connectors and telephony: reviewed separately.
Entra ID and identities
Preparation and mappingContent migration does not migrate identities. Target users must be created and mapped correctly before data is moved.
- UPN, proxyAddresses and required attributes.
- Cross-Tenant Identity Mapping where appropriate.
- Groups, B2B, MFA and Conditional Access are reviewed separately.
Domain and DNS
Critical cutoverThe domain must be free of references in the source tenant before it can be added to the target. It is treated as a cutover phase, not as a minor administrative task.
- UPNs, aliases, groups and objects that still reference the domain.
- MX, SPF, DKIM and DMARC.
- Validation of sending, receiving and DNS resolution.
Intune and devices
ReconfigurationA tenant move may require device re-enrollment or reprovisioning, and configuration may need to be recreated or adapted.
- Profiles, apps, compliance and Autopilot.
- Re-enrollment and communication plan.
- Review of identity and security dependencies.
Power BI and Power Platform
Scope dependentWorkspaces, reports, models, connections, gateways, flows and applications must be assessed individually.
- Inventory and criticality.
- Permissions, connections and credentials.
- Recreation or migration according to the component and available tools.
A controlled project starts by defining scope and impact before cutover
The methodology adapts to the environment, but the principle is always the same: reach cutover with the important decisions already made, the target prepared and a procedure the client's team understands in advance.
The migration is designed before the cutover window begins
Assessment is used to determine workload method, identity and domain dependencies, target readiness, user impact and validation criteria before production changes are executed.
Objectives and scope
Which tenants are involved, which workloads are included, responsibilities, constraints and target change window.
Technical inventory
Users, mailboxes, sites, Teams, groups, domains, identity, retention, apps and devices.
Architecture and mapping
Target tenant, identity, domain, workload-specific method, migration waves and dependencies.
Target preparation
Users, permissions, licenses, tools, trust relationships, DNS and controls.
Method validation
Representative testing to confirm timing, permissions, user experience and the runbook.
Preloads and preparation
Pre-cutover work where the workload and tool support staging or delta passes.
Controlled change
Execution, domain/DNS, batch completion, critical validations and communication.
Stabilization
Enhanced support, functional validation, issue handling, documentation and closure.
What the client receives in a tenant-to-tenant migration project
The client receives more than a completed migration. They receive a traceable project: what was decided, what was moved, how it was done, what was validated and what remains after the change.
Environment assessment
Inventory of workloads, users, domains, dependencies, volume and the factors that influence the migration method.
Source-to-target mapping
Mapping of users, mailboxes, groups, sites, Teams, domains and other objects included in scope.
Technical migration plan
Method per workload, prerequisites, tools, execution order, waves and responsibilities.
Cutover plan
Task sequence for the change, Go/No-Go criteria, DNS, validations and coordination with the client's team.
Validation and evidence
Agreed checks covering data, access, permissions, email, collaboration and critical elements after the move.
Closure and handover
Summary of issues, outstanding items, changes made, recommendations and removal of temporary access where appropriate.
Stabilization support
Support for issues linked to the migration during the support period defined in the project scope.
Next steps
Recommendations on security, governance, licensing or architecture where the target tenant requires a follow-on phase.
What users may notice during a tenant-to-tenant migration
We do not promise that every workload will be invisible to users. We define the expected impact, communicate it and prepare the cutover so the change is predictable and support can respond quickly.
Depending on the selected method, users may need to sign out and back in, recreate or update their profile, and complete post-migration validation of Autodiscover, email and calendar.
With the native migration method there may be a short read-only period. We then validate access to the new OneDrive and client synchronization.
A change window is communicated for affected sites, followed by validation of access, permissions, links and content after migration.
Users move to their target identity and may need to reconnect teams, meetings or elements that were not moved natively.
This is one of the most sensitive steps. Releasing the domain from the source tenant, adding it to the target and changing DNS must be precisely sequenced.
When included in scope, the user experience depends on the re-enrollment method and device type. A specific user and support plan is prepared.
Administrative access limited to what the project requires
The migration requires technical permissions, but those permissions should be defined, controlled and removed when they are no longer needed. The exact model is adapted to the client's restrictions and the tools used.
During the project
- Administrative roles and accounts defined for the required scope.
- MFA and access controls compatible with technical execution.
- PIM, temporary permissions or equivalent models where the environment and client allow them.
- Applications, service principals and consents documented.
- NDA and alignment with internal security procedures where applicable.
At project completion
- Review and removal of permissions that are no longer required.
- Removal or revocation of temporary applications and consents where appropriate.
- Delivery of evidence, reports or documentation defined in scope.
- Validation that day-to-day administration is returned fully to the client.
- Security and governance recommendations for the target tenant.
How the cost of a Microsoft 365 tenant-to-tenant migration is calculated
We publish 'from' prices to provide an initial indication of cost. The final proposal is based on the actual scope, so you do not pay for workloads or tools the project does not need.
User mailbox
€25From / mailbox
- Standard mailbox scope.
- Preparation and validation according to the project.
- Licenses and additional items quoted separately.
User account
€10From / account
- Personal content migration.
- Mapping and validation according to the selected method.
- Volume and exceptions may affect cost.
Team
€40From / team
- Structure and collaboration according to scope.
- Associated files coordinated with SharePoint.
- Chats, meetings, apps and voice reviewed separately.
Site or group
€40From / site
- Standard sites and libraries.
- Permissions, groups and metadata according to scope.
- Apps, automations and taxonomy may require additional work.
What we need to size the project
With this information we can prepare a reasonably accurate initial estimate and quickly tell you whether a deeper assessment is needed before a fixed proposal can be issued.
How we choose between Microsoft native capabilities, specialist tools and a mixed approach
There is no single migration tool that is best for every tenant. The decision depends on the workloads in scope, the state of the source and target, coexistence requirements, reporting needs and the elements Microsoft does not cover natively.
When the scenario fits the requirements
A strong option for workloads with supported cross-tenant capabilities and a target environment prepared to Microsoft requirements. It reduces intermediaries and keeps the move within the Microsoft ecosystem.
When broader coverage or control is required
Useful for Teams, advanced coexistence, reporting, transformations, complex batch migrations or elements that do not have an equivalent native path.
Common in complex projects
Combines native capabilities, specialist tools and automation so each workload uses the most appropriate method instead of forcing the whole project onto one platform.
What we assess before choosing the tooling
What we avoid
We do not recommend a tool simply because it was used on another project. A platform can be excellent for email and not the best fit for Teams, or provide features that do not justify the cost for a smaller tenant.
Quest On Demand Migration, Cloudiway, BitTitan, AvePoint, ShareGate and Microsoft-native capabilities
MSAdvance does not force every tenant-to-tenant project onto one migration platform. We maintain direct partner relationships with selected vendors in this ecosystem and combine their tooling with Microsoft-native capabilities, PowerShell and Microsoft Graph according to the workloads, coexistence requirements, reporting needs and project constraints.
Quest On Demand Migration
Our preferred specialist platform for complex Microsoft 365 tenant-to-tenant programs, particularly M&A, carve-outs and multi-workload migrations where centralized project control, wave planning, coexistence and reporting matter.
Cloudiway
A strong option when the project extends beyond a straightforward Microsoft-to-Microsoft move or when coexistence is a significant part of the transition.
BitTitan MigrationWiz
A practical SaaS option for clearly scoped cloud-to-cloud migration projects where rapid setup, repeatable migration batches and straightforward mailbox or document workloads are priorities.
AvePoint Fly
Useful where the migration includes a broad Microsoft 365 content estate, advanced discovery or Power Platform components in addition to the core collaboration workloads.
ShareGate Migrate
Particularly valuable for content-heavy Microsoft 365 projects where information architecture, permissions, metadata, versions, authorship and restructuring need close attention.
Microsoft-native migration capabilities
When Microsoft provides a native route that fits the scenario, we consider it before introducing another platform. Native and specialist tooling can also be combined within the same program.
What Microsoft provides natively
Microsoft has significantly expanded its tenant-to-tenant capabilities. This makes native services viable in more scenarios, but it does not turn every workload into one automatic migration. Migration Orchestrator is currently documented by Microsoft as a preview capability, so availability, behavior and requirements should be revalidated during project assessment.
Migration Orchestrator
Orchestrates personal user content. It currently covers Exchange mailboxes, OneDrive, Teams chats and Teams meetings. Shared data such as teams/channels and SharePoint sites are not moved within that same scope.
Official Microsoft documentationExchange cross-tenant
Moves mailboxes between tenants subject to target object preparation, organization relationships and Cross-Tenant User Data Migration licensing. Mailboxes with holds can be blocked.
Cross-tenant mailbox migrationOneDrive cross-tenant
Microsoft moves the content within Microsoft 365. The target OneDrive must not already be provisioned and the native move is a single-pass operation.
Cross-tenant OneDrive migrationSharePoint cross-tenant
SharePoint sites can be moved between tenants using PowerShell and identity mapping. Microsoft states that up to 4,000 migration jobs can be queued at the same time.
Cross-tenant SharePoint migrationCross-Tenant Identity Mapping
CTIM helps map source and target users and prepare the attributes required for migration. It is an identity preparation and matching component, not a copy of user data.
Cross-Tenant Identity MappingDependency planning
Microsoft recommends planning identity, domain and workload sequence together. Teams depends on Exchange in certain scenarios, while OneDrive and SharePoint share permission models.
Plan a tenant-to-tenant migrationHow we apply this at MSAdvance: we use native capabilities when they fit the scope and licensing. When a workload or requirement is not covered, we define an additional path using specialist tools, automation or reconfiguration. The goal is the right project outcome, not forcing a single tool.
What should be confirmed before finalizing scope
A reliable proposal should make clear from the outset which elements are directly supported, which require preparation and which may need reconfiguration. These are some of the points we review before committing to method and scope.
Content migration does not create the final corporate identity by itself. Users must be created and mapped, and groups, roles and policies reviewed.
Migration Orchestrator does not move shared team and channel data. The project needs an additional strategy for structure, files and configuration.
Teams, SharePoint and third-party integrations may need to be reconfigured or reinstalled in the target tenant.
Devices may require re-enrollment and configuration should be assessed before the move.
Legal retention and certain policies can block or change the native migration path and must be identified before execution.
Native capabilities have strict requirements around pre-existing target accounts or sites and do not behave like a generic merge operation.
What we validate before approving the cutover
Most serious migration issues are not caused by copy speed, but by a dependency that was missed beforehand. This is the minimum checklist we review before approving the change window.
Common questions about tenant-to-tenant migrations
What is a Microsoft 365 tenant-to-tenant migration?
It is the process of moving data and services from one Microsoft 365 tenant to another. It can include Exchange Online mailboxes, OneDrive, SharePoint, Teams, identities, domains, groups and other components. Each workload has its own method and requirements. It may also appear in older search terms or documentation as an Office 365 tenant-to-tenant migration.
Can everything be migrated automatically?
No. Microsoft provides important native capabilities, but the Microsoft 365 ecosystem does not move in one uniform way. Shared Teams data, apps, tabs, telephony, Intune, Power BI, Power Platform and some configurations may require additional tools or reconfiguration.
What does Migration Orchestrator support?
Microsoft's current documentation lists four workloads for personal user content: Exchange mailboxes, OneDrive, Teams chats and Teams meetings. Shared data such as teams/channels and SharePoint sites are not moved within that same scope; SharePoint has a separate cross-tenant capability.
How long does a tenant-to-tenant migration take?
It depends on the number of users, email and file volumes, the number of sites and Teams, domain complexity, identity, throttling and the method used for each workload. An assessment makes it possible to estimate timings by wave and define the actual cutover window.
Does the domain have to move?
Not in every project. When the corporate domain must move to the target tenant, its references need to be removed from the source tenant, the domain released, added to the target and identities and DNS updated at the planned time.
Can OneDrive already contain data in the target tenant?
For Microsoft's native cross-tenant capability, the target OneDrive must not already be provisioned. If target content already exists, a different strategy needs to be assessed rather than assuming an automatic merge.
Can Teams, channels and chats be migrated?
They can all be part of the project, but they do not all follow the same method. User chats and meetings have native capabilities; shared team and channel data require an additional approach, usually involving specialist tooling and controlled recreation.
What happens to SharePoint and OneDrive permissions and links?
Native capabilities use identity mapping to preserve permissions for included users and groups. Microsoft can also create redirects from source to target for migrated content. Links, external access, integrations and permissions should still be validated after the move.
Can mailboxes on legal hold be migrated natively?
Microsoft documentation states that mailboxes with holds can be blocked from cross-tenant migration. Retention and eDiscovery requirements therefore need to be reviewed during assessment.
Can MSAdvance work with our internal IT team?
Yes. That is the usual model for projects of this type. MSAdvance can own assessment, architecture, configuration, tooling, execution and validation while coordinating with internal owners for identity, DNS, security and support.
Can we run a pilot before cutover?
Yes, and it is recommended for medium or complex projects. The pilot validates mappings, timing, permissions, user experience and the procedure before the main migration waves.
Why use a specialist company for a tenant-to-tenant migration?
Because the main risk is usually in coordinating workloads, identities, domains, security and user experience, not simply copying data. A specialist team can identify dependencies before cutover, select the right method per workload and take responsibility for execution and validation.
What information do you need to provide a quote?
At minimum: number of users and mailboxes, OneDrive accounts and approximate volume, number of SharePoint sites and Teams, domains involved, identity model, other workloads and the planned change window. With that information we can prepare an initial estimate and determine whether a deeper assessment is required.
Technical resources for evaluating a Microsoft 365 tenant-to-tenant migration
This service page summarizes the offering. These guides go deeper into the workloads and decisions IT teams typically review before commissioning or executing a project.
Microsoft 365 tenant-to-tenant migration
General guide covering architecture, coexistence, workloads, cutover and validation.
Read guideTools and scripts for Microsoft 365 tenant migration
Microsoft native capabilities, Quest, BitTitan, PowerShell and criteria for choosing the right approach.
Read guideOneDrive migration between tenants
Identity, permissions, target preparation and the specifics of cross-tenant moves.
Read guideSharePoint migration between tenants
Sites, libraries, permissions, pages, hubs, automations and integrations.
Read guideMicrosoft Teams migration between tenants
Teams, channels, chats, meetings, files, applications and identity dependencies.
Read guideReal tenant-to-tenant migration project
Context, volumes, decisions, issues and outcomes from a Microsoft 365 consolidation.
View case studyTell us what you need to move and we will help turn it into a viable project
Send us the tenants involved, users, mailboxes, OneDrive, SharePoint, Teams, domains and any other relevant components. We will review the scenario, identify any missing information, highlight the points that need attention and explain how we would structure the project.
