Microsoft 365 Tenant-to-Tenant Migration
Two companies can agree to combine before their Microsoft 365 environments are ready. NetSys helps scope which people and data move, what stays separate and how the business will work through the transition.
The short answer
Microsoft 365 tenant-to-tenant migration services move agreed users and business content between separate Microsoft 365 organizations. NetSys scopes mergers, divestitures and consolidation around identities, domains, email, OneDrive, SharePoint, Teams, applications and device dependencies. The migration plan defines the method, licenses, coexistence, exceptions and acceptance for each workload; mailbox movement alone does not consolidate the whole environment.
Start with the business decision: one organization acquiring another, several tenants being consolidated, or a team moving to a different environment. Identify the destination tenant, who is authorized to approve the change, which people are in scope and which business units must remain separate. Those decisions determine the account, domain and access plan; a transfer tool cannot make them for you.
Bring the source and destination tenant details, approximate user counts, workloads, known business applications and any contractual deadline. We use those inputs to scope discovery and the migration plan. Existing target accounts, shared addresses, external collaborators, retention requirements and applications using Microsoft sign-in need review before a cutover date is agreed. Administrative access is arranged through an approved secure process; do not send passwords through the contact form.
Approve the move by workload, then test the working day
A representative pilot should cover sign-in, mail delivery, shared access, important files and the collaboration people actually use. Agree which exceptions block the move, who can accept an exception and what recovery options exist for the selected method. Some native moves remove source content or cannot be repeated as incremental passes, so source preservation and recovery decisions belong before cutover. Completion means the agreed business checks pass and remaining issues have named owners, not simply that a transfer job reports success.
What a tenant migration project can include
Discovery, ownership and migration scope
Find the dependencies that a user count alone cannot describe.
- Source and destination tenant owners, approval contacts and in-scope users
- Mailbox, domain, OneDrive, SharePoint and Teams inventory
- Business applications, shared access, guest users and device dependencies
- Retention, holds, excluded content and business-owner acceptance criteria
Identity, domain and authorized access planning
Give each person and business address an agreed destination.
- Source-to-target account mapping and checks for existing target content
- Domain ownership, sign-in names, aliases and mail-routing decisions
- Required administrative roles, application consent and scoped permissions
- Destination access policies and a plan to remove temporary migration access
Method selection and pilot migration
Choose tools against the required data and tenant conditions.
- Microsoft-native versus third-party method review for each workload
- License eligibility, supported content and documented migration limits
- A representative pilot with permission, content and access validation
- A separate plan for workloads, applications or content the selected method does not move
Cutover, validation and user support
Coordinate the change with the people who must work through it.
- Agreed migration waves, communication, access windows and escalation contacts
- Mail delivery, sign-in, file access, sharing and selected collaboration checks
- User instructions, recorded exceptions and business-owner acceptance
- Defined transition support, source-retirement decisions and ongoing tenant ownership
Keep business decisions and technical dependencies in one plan
Tell us whether this is a merger, consolidation or tenant move, along with the approximate user count, workloads and deadline. We will identify the discovery needed to scope the migration, licensing and support.
Who does the work: meet the NetSys team on our About page.
- Named owners approve the people, workloads and domains in scope
- Native and third-party limitations are checked before tool selection
- Migration, application remediation and ongoing support have explicit boundaries
- Pilot evidence and agreed acceptance checks guide the cutover decision
Which migration page you need
This page covers moving between two Microsoft 365 organizations. Moves from other platforms are on these pages.
| Page | Use it when |
|---|---|
| This page: Tenant-to-tenant migration | Two Microsoft 365 organizations are merging or separating after an acquisition or divestiture. |
| Microsoft 365 migration | You are moving mail, files and collaboration into Microsoft 365 from Google Workspace, Exchange or another platform. |
| Business email migration | Only the mailboxes and mail flow are moving, not the files, Teams or the rest of the workspace. |
| Microsoft 365 to Google Workspace | You are moving the other way: out of Microsoft 365 and into Google Workspace. |
| SharePoint migration | A file server or shared drive is moving into SharePoint and OneDrive with a new permission model. |
Related pages: Microsoft 365 migration · Business email migration · Microsoft 365 to Google Workspace · SharePoint migration.
A migration-and-exceptions register for each workload
The chosen method and current platform support determine what can move and what must be recreated or handled separately.
| Workload | Scope decision | Exception or acceptance check |
|---|---|---|
| Identities and domains | User mapping, sign-in design, domain ownership and authority | Application sign-ins, admin access and domain sequencing |
| Mailboxes, addresses, delegates and routing | Archive, retention, shared access and mail-flow tests | |
| OneDrive and SharePoint | Content owners, destination structure and permissions | Links, sharing, versions and data-owner validation |
| Teams | Teams, channel content and the artifacts supported by the method | Document what will not transfer identically and how users will work afterward |
| Applications | Enterprise apps, integrations and consent or credential changes | Vendor support and representative end-to-end transactions |
| Devices | Join/enrollment, management policies and user profile impact | User sign-in, compliance and access after the change |
Merger and divestiture decisions to settle early
Access to both tenants and agreement between the organizations are project prerequisites.
| Decision | Owner or evidence |
|---|---|
| What belongs in the move | Authorized business owners approve users, content and exclusions |
| Who controls each tenant | Named administrators, permission approvals and escalation contacts |
| How long both environments coexist | Mail routing, collaboration expectations and support responsibilities |
| When to cut over | Business freeze windows, dependencies and a documented go/no-go decision |
| When to close the source | Acceptance, retention, backup and remaining contractual responsibilities |
Use the buyer checklist before selecting a tool
A tool should fit the approved scope; its feature list should not define the business decision.
- Agree the workloads, success checks and exceptions before comparing migration methods.
- Test a representative user and difficult content, including access that should be denied.
- Plan first-day support, communication and the process for unresolved issues.
- Record licensing and tool costs separately from engineering and ongoing tenant management.
Microsoft 365 Tenant-to-Tenant Migration FAQs
Will Teams, identities and applications migrate exactly like mailboxes?
No. They have different dependencies and migration support. Record the supported content, configuration that must be recreated, permissions, integrations and user changes for each workload. Use a pilot and written exceptions rather than promising that a single tool will make two tenants identical.
What do we need from the other organization before a tenant move?
Authorized access, data and user scope decisions, domain and identity ownership, licensing, the coexistence plan and people who can approve the cutover. In a divestiture or acquisition, confirm who may authorize data transfer and what retention or separation obligations apply before migration starts.
How is a tenant migration different from email or SharePoint migration?
A tenant migration coordinates the move between two established Microsoft 365 organizations, including the account, domain and workload dependencies agreed in scope. Email migration focuses on mailboxes and mail flow. SharePoint migration focuses on business files and sites. If only one workload needs to move, scope that smaller project; if a merger changes several workloads and how people sign in, use a coordinated tenant plan. A subscription change inside the same tenant is not automatically a tenant migration.
Can we use Microsoft’s native tools, or do we need a third-party tool?
It depends on the workloads, target environment, licensing and required behavior. Microsoft’s user-data migration options require eligible licenses and tenant preparation. Its native cross-tenant SharePoint shared-data option is currently limited to Enterprise Agreement customers. Native OneDrive and SharePoint cross-tenant moves are one-time moves, without incremental or delta passes; they also have destination and content restrictions. We check the applicable requirements and compare alternatives before recommending a method. Third-party tools have their own licenses, permissions and data limits; none should be assumed to move everything.
Can Teams chats, meetings and SharePoint sites move?
Microsoft’s current Migration Orchestrator supports eligible Exchange mailboxes, OneDrive content, Teams chats and Teams meetings, subject to its prerequisites and workload limits. That does not include every shared collaboration asset: Teams and channels, and SharePoint sites, are outside that user-data orchestration scope and require a separate assessed approach. We inventory what the business needs, identify supported methods and document exceptions. Apps, automations, links and permissions may need additional configuration and testing rather than simply being copied.
Can staff keep their email addresses and access to shared information?
The plan can retain business addresses where the organization controls the domains and the destination configuration supports the intended arrangement. Domain transfer, sign-in names, aliases and temporary mail routing need an agreed sequence. Access also depends on correctly mapping people and groups, preparing target accounts and checking shared or delegated permissions. Microsoft’s orchestrator moves content rather than identities, so account preparation is separate work. We validate representative access instead of assuming that the same display name creates the same permissions.
Will everyone be able to work during the move?
The plan identifies expected interruptions and user actions for each workload and migration wave. Duration depends on tenant readiness, data, selected tools and service processing; a calendar booking is not a guarantee that every workload finishes at the same time. Agree a pilot, communication plan, go/no-go checks and an escalation route. Users may need to sign in again or reconnect applications. Record-preservation and recovery requirements must be resolved before moves that remove source content, and source subscriptions should be retired only after the agreed review.
What determines the cost of a Microsoft 365 tenant migration?
User count is one input. Data volume, workloads, existing target accounts, domains, application dependencies, permissions, retention requirements, migration method and support needs also affect the work. The quote should separate discovery, migration labor, Microsoft or third-party migration licenses, destination subscriptions, application remediation and transition support. A merger involving files and collaboration needs a different scope from a mailbox-only move. Share the current environments and deadline so the estimate can be based on the actual project.
Sources and technical references
- Microsoft: cross-tenant mailbox migration requirements and scope
- Microsoft: tenant-to-tenant planning and business scenarios
- Microsoft: orchestrator workloads, licensing and exclusions
- Microsoft: identity mapping and migration prerequisites
- Microsoft: native SharePoint migration eligibility and limits
- Microsoft: native OneDrive cross-tenant migration
- Microsoft: migration timing and recovery considerations
Guides on this topic
- Compare platform migration
- Scope mail-only work
- Plan file and site migration
- Tenant-to-tenant migration: buyer questions
- Microsoft 365 management after the move
- Backup and recovery planning for Microsoft 365
- Assess technology before an acquisition
- Coordinate access, network and support work around a tenant integration
Agree what moves and what needs a separate decision.
Bring the source and destination tenants, the merger or separation scenario, user and workload counts and your deadline. We will define discovery, coexistence and acceptance.