Microsoft 365 tenant coexistence: planning and operation

Designing coexistence based on how employees work.

Coexistence between Microsoft 365 tenants should be based on the specific actions that individuals from both organizations need to perform. Being able to send an email to a colleague does not guarantee that you can check their availability, share a document with them, or collaborate within a channel. Each workflow must be tested in both directions, as the inbound and outbound policies of each tenant may yield different results.

For example, during an acquisition, a sales team might need to check calendars and collaborate on proposals before their accounts are actually migrated. The design must identify where documents reside, which account each person will use, and who manages permissions. This decision prevents the same work from being spread across duplicate folders and teams without a clear owner.

The inventory of use cases is subsequently transformed into a test matrix: source user, target resource, permitted action, and expected outcome. If an invitation works, but the user cannot open the file from the application they use on a daily basis, the case is not yet resolved. The acceptance process must verify this entire workflow and document any limitations that have been communicated.

Coexistence also requires an end date and a decommissioning procedure.

A temporary arrangement can evolve into an architecture that is difficult to maintain if no one defines when it should end. Every connection, external user, and exception must have a clear purpose and an assigned owner. If consolidation is planned, the strategy must specify what will happen to these access points once users transition to the final, permanent tenant. Simply migrating accounts does not automatically eliminate all the relationships created during the transition period.

The decommissioning process begins by reviewing groups, external access, mail routing, and resources that are still being used from the previous environment. Before removing a relationship, the owner must confirm that an operational alternative is in place. This verification ensures that an administrative cleanup does not disrupt a project that still relies on a document or an application shared between the two organizations.

What it really means to have coexistence between Microsoft 365 tenants.

A Microsoft 365 tenant is an independent administrative boundary. It has its own Microsoft Entra ID directory, users, groups, licenses, security policies, Exchange Online, SharePoint, OneDrive, Teams, applications, and configuration. Therefore, having two tenants is not the same as having two servers within the same domain. Each environment maintains its own identity and services. Coexistence involves configuring collaboration and routing mechanisms between both tenants for as long as is necessary to complete the transition..

A simple example

Suppose one company acquires another organization with 500 users. They do not want to migrate all 500 users over the same weekend. Instead, they decide to move them in five batches of 100 users. After the first batch, we have:

Without coexistence, both groups might immediately encounter issues. These could include: being unable to find colleagues when scheduling meetings, an inability to accurately check their availability, problems with emails sent to the corporate domain, difficulty locating the same Teams, loss of access to shared documents, and the need to constantly switch between organizations. Coexistence aims to mitigate precisely these types of issues while the migration is being completed.

When is coexistence typically necessary?

Not all migrations require the same level of coexistence. A company with 20 users that can complete the entire transition over a weekend will likely need far less temporary infrastructure than an international organization migrating 5,000 users over the course of four months.

Mergers and acquisitions. It is common for two companies to need to collaborate well before IT can consolidate all their systems. In such cases, coexistence may begin with identity, Teams, and document access, while the migration of email and data is prepared in parallel. Spin-offs and divestitures. The challenge is different. It is not just about enabling collaboration, but rather about reducing dependencies between two organizations that must ultimately become separate entities..

Any temporary configuration must be designed with its eventual removal in mind from the very start. Phased migrations (migrations in waves). For large-scale projects, this is often one of the most sensible approaches. Users can be grouped by: country, department, legal entity, location, business unit, or technical complexity. Coexistence allows each wave to migrate without waiting for the entire project to be completed.

What a coexistence architecture does not solve.

This point is important because many misconceptions arise even before the project begins.

The most significant limitation: a custom domain cannot exist in two tenants.

This is arguably the most significant constraint in any tenant-to-tenant migration. A domain, such as: empresa.com can only be verified in one Microsoft Entra / Microsoft 365 tenant at a time. Furthermore, Microsoft does not allow the following namespaces to be shared across tenants: UPN, SMTP, and SIP. What this means in practice. As long as empresa.com it belongs to tenant A, we cannot verify that same domain in tenant B.

Therefore, prior to the cutover, destination users are typically prepared using: usuario@tenantdestino.onmicrosoft.com or a temporary domain/subdomain suitable for the design. When the time for the cutover arrives, it will be necessary to remove any references from the source tenant that prevent the domain from being released; once removed, it can then be added to and verified in the destination tenant.

Changing the MX record is not enough.

The domain is involved in much more than just email.

Microsoft also documents that, before removing a domain, it must no longer be in use by users, administrators, shared mailboxes, resources, contacts, groups, distribution lists, or Teams. Official reference: Microsoft – Remove a domain from Microsoft 365.

General coexistence architecture.

Instead of looking for a single tool to handle “coexistence,” it is more useful to break the problem down by service.

Identity: Microsoft Entra B2B as the foundation for collaboration.

Before discussing Teams or SharePoint, we need to address identity. When a user from one organization needs to access resources in another, Microsoft Entra can represent them via B2B collaboration. B2B collaboration. The user continues to authenticate using their original credentials, but an object representing them exists within the tenant that holds the resources. This model is suitable for scenarios such as: accessing SharePoint, participating as a guest in Teams, accessing enterprise applications, collaboration between companies, and shared projects.

A user is not “migrated” simply by being added as a guest. Their primary identity remains associated with the original tenant. This is particularly important during an acquisition. It allows employees to quickly access specific resources belonging to the acquiring company without the need for an immediate migration: mailbox, OneDrive, devices, applications, domain.

Cross-tenant access settings: determining who to trust and for what purpose.

Cross-tenant access settings These settings allow you to control the relationship between your tenant and other Microsoft Entra organizations. You can configure specific policies for each organization, rather than treating all external entities in the same way. Inbound and outbound access.

You can also restrict applications. You do not have to open up your entire organization. For example, you can allow access for: a specific group of users, or a specific application. Trust settings. One of the most significant capabilities is the ability to trust certain claims issued by an external tenant—for example: MFA, device compliance, and Microsoft Entra hybrid-joined device status. Practical example. Your Conditional Access policy requires MFA for external users.

If we have established a trust relationship for MFA with the associated tenant—and the user has already successfully completed MFA there—our tenant can accept that signal. This allows us to maintain control without necessarily forcing the user to repeat the same process. Do not automatically trust just any tenant. Before accepting signals from another organization, we should be aware of: their MFA policy, their permitted authentication methods, how they manage devices, and the level of control they apply to identities.

Official reference: Microsoft – Cross-tenant access overview.

Cross-tenant synchronization: automating the management of users and specific groups.

When collaborating with ten users, manual B2B invitations are perfectly manageable. However, when you need to maintain hundreds or thousands of external identities over several months, the situation changes. Cross-tenant synchronization automates provisioning between tenants within an organization. What it does: It can create, update, and delete B2B representations in the target tenant based on objects from the source tenant.

It is a one-way process. A configuration consists of: source tenant → target tenant. If two-way synchronization is required, you must create the corresponding configurations for each direction. Important update: group synchronization. Current Microsoft documentation also allows for the synchronization of specific groups.

However, there are limitations. This should not be interpreted as a general synchronization of all Microsoft 365 groups. Currently, it does not create the following in the target environment: Microsoft 365 Groups (as such), distribution groups, dynamic distribution groups, mail-enabled security groups, role-assignable groups, or nested groups. Furthermore, it is not a migration tool. Synchronized users continue to authenticate against their source tenant. Cross-tenant synchronization also does not migrate: mailboxes, OneDrive, SharePoint, Teams, or devices.

Official reference: Microsoft – Cross-tenant synchronization.

Multitenant Organization: when multiple tenants actually belong to the same company.

Not all coexistence scenarios end with a single tenant. Some organizations decide to maintain multiple tenants permanently due to: legal structure, regional autonomy, regulatory requirements, acquisitions, or operating models. For these cases, Microsoft offers the following functionality: Multitenant Organization. What it represents. Allows for the definition of a perimeter for tenants that belong to the same organization. It does not merge their directories. The tenants remain independent, but Microsoft can offer more consistent collaboration experiences across them.

Microsoft 365 people search. One of the traditional challenges in a multi-tenant architecture is that searching for people is typically limited to the local tenant. Within a Multitenant Organization—combined with appropriate B2B provisioning—Microsoft can improve the ability to find colleagues from other tenants across Microsoft 365 experiences. Microsoft Teams. Microsoft also uses the Multitenant Organization framework to enhance specific experiences for users who belong to different tenants within the same corporate group.

Do not use it for an external provider.

Multitenant Organization is designed for tenants that belong to the same organization.For collaboration between independent companies, you should continue to use the appropriate B2B models. Official reference: Microsoft – Multitenant Organization.

Email coexistence with Exchange Online.

Email is usually the aspect most visible to users. During a phased migration, we must ensure that an employee who was migrated yesterday can seamlessly send messages to another employee who will remain in the source tenant for another three weeks. What needs to be maintained.

Mail routing during a phased migration.

There is no single design that applies to all projects. It will depend on: which tenant holds the primary domain, where the MX record points, which migration tool is used, and what objects exist in each organization. Routing domains. It is common to use technical domains such as: tenantA.onmicrosoft.com and tenantB.onmicrosoft.com to route messages without requiring the corporate domain to be associated with both tenants simultaneously.

MailUser and targetAddress. In certain designs, the tenant that does not contain the mailbox maintains a mail-enabled object that is aware of the recipient’s actual location. The routing attribute can direct the message toward a technical address in the tenant where the mailbox resides. Internal Relay. Depending on the architecture, an accepted domain can be configured as Internal Relay so that Exchange searches for the recipient locally and, if not found, continues routing to the appropriate system.

This must be tested carefully. An incorrect configuration can lead to: loops, NDRs (non-delivery reports), delivery to the wrong mailbox, or messages remaining within the incorrect tenant. Do not copy a routing design without understanding it. A scheme that is correct for one organization may be unnecessary or even dangerous for another. Before creating connectors or Internal Relay domains, it is advisable to document the flow: Internet → gateway → Exchange Online → recipient → potential second tenant.

Domain cutover: the most critical moment.

At some point, if the organization wishes to retain the corporate domain in the destination tenant, it will need to release it from the source tenant. Before the cutover. All relevant references to the domain must be removed or changed.

After. The standard workflow is: Remove from the source → add/verify in the destination → configure users/addresses → update DNS. DNS. It is advisable to prepare the following in advance: MX records, Autodiscover (where applicable), SPF, DKIM, DMARC, and any records required for dependent services. Reducing the TTL helps, but it does not allow the domain to be released any sooner. Lowering the TTL before the cutover can accelerate the propagation of new DNS values. It does not eliminate internal Microsoft 365 dependencies, nor does it allow a domain to remain verified in two tenants simultaneously.

Calendars and free/busy information across tenants.

The second issue that users quickly notice during a migration concerns the calendar. When they attempt to invite a colleague from the other tenant, they still want to be able to see their status: Free, Busy, Tentative, or Out of Office. Organization relationships. Exchange Online allows for the creation of Organization Relationships between organizations to share calendar information. Levels of information. You can share only availability (free/busy status) or include specific additional details, depending on the configured level.

Illustrative example

Connect-ExchangeOnline -UserPrincipalName admin@tenant-a.com

New-OrganizationRelationship `
    -Name "Tenant B - FreeBusy" `
    -DomainNames "tenantb.com" `
    -FreeBusyAccessEnabled $true `
    -FreeBusyAccessLevel LimitedDetails

In the other tenant, you configure the corresponding relationship if you need data exchange in both directions. What it achieves. It can make a phased migration much more convenient, as users from both tenants can check each other’s availability. What it does not achieve. It does not migrate: calendars, delegations, rooms, resource mailboxes, calendar permissions, or historical bookings. Rooms and resources require a specific plan. If an office continues to use rooms hosted in the source tenant while some of its users have already moved to the destination tenant, you must define who retains authority over bookings and what the user experience will be like during that period.

Official reference: Microsoft – Create an organization relationship in Exchange Online.

Microsoft Teams: three distinct collaboration models.

Simply saying “we will enable Teams between tenants” is not sufficiently precise.

External access. Appropriate when the primary need is to: Find an external person, chat, call, or invite them to meetings. Does not provide general access to the other organization’s teams or documents. Guest access. The user joins a team hosted in the host tenant as a guest. This is a good option when the user needs to be part of a full collaboration space.

Shared channels. Shared channels allow for sharing only a specific channel with people who are not part of the entire team. For external participants, this relies on Microsoft Entra B2B direct connect. B2B direct connect. Unlike traditional guest access, the user can access the shared channel using their original identity, without needing to operate as a conventional guest within the host tenant.

Must be enabled in both organizations. B2B direct connect is blocked by default in cross-tenant access settings. To collaborate, both organizations must permit the corresponding relationship. Currently, its primary use case is Teams shared channels. We should not treat B2B direct connect as a general replacement for B2B collaboration for every application. Official reference: Microsoft – B2B direct connect overview. A shared channel is also not a form of Teams migration.

It can assist us during a transition, but the content remains the property of the tenant where the channel is hosted. Once the coexistence period ends, we must decide: whether it should remain there, be migrated, be recreated, or be archived.

SharePoint and OneDrive during coexistence

Documents are generally more difficult to manage than email because permissions accumulate over time. During coexistence, it is best to avoid the “quick fix” approach of: “sharing everything with everyone and fixing it later.” Temporary access must also be governed.

OneDrive should not become a temporary departmental repository. During a migration, it is tempting to share folders from a user’s OneDrive so that everyone can continue working. If the information actually belongs to a team or department, it may be better to use the migration project as an opportunity to determine its proper destination: SharePoint or Teams. Temporary permissions with an expiration date.

A best practice is to document: what access was granted, to whom, why, and when it will be reviewed.

Coexistence should not compromise security

Migrations create pressure. Users need access, and IT needs to resolve issues quickly. This is precisely when it is easiest to introduce exceptions that end up remaining for years. Controls that should be maintained.

Do not trust external MFA without evaluating the tenant. Cross-tenant access settings allow for trusting MFA performed by another organization. While this greatly improves the user experience, it also means accepting a security decision made by an external tenant. In the case of a merger, this may be perfectly reasonable, but it should be preceded by an evaluation. Access Reviews. A coexistence period initially planned for four weeks could end up lasting six months.

During that time: People change roles, leave the company, or finish projects, meaning they no longer require access. Periodic reviews help prevent B2B objects from inadvertently becoming permanent permissions.

Coexistence and migration are two connected, yet distinct, projects

A well-managed coexistence facilitates migration. However, one must not confuse: granting access with moving content.

Migration Orchestrator in 2026

Microsoft is developing Migration Orchestrator a solution to coordinate tenant-to-tenant migrations for various workloads. As of the date this guide was updated, Microsoft’s own documentation still describes this solution as preview. Workloads that can currently be coordinated. Microsoft documents four main workloads:

This does not mean that the entire Teams environment is migrated. Microsoft indicates that the solution does not include the following within its scope: Shared Teams and channels, nor the associated shared SharePoint sites. Dependencies. Teams meetings have a dependency on Exchange. When migrating multiple workloads for the same user, Microsoft recommends handling them in a coordinated manner to account for these dependencies. Migration Orchestrator moves content, not identities.

Users in the target tenant must be properly prepared before the migration takes place. The creation and configuration of identities remain the responsibility of the project team. Official reference: Microsoft – Migration Orchestrator overview.

Cross-tenant migration for Exchange Online

Microsoft provides a native capability for moving Exchange Online mailboxes between tenants, utilizing technologies such as: Exchange Online PowerShell and the Mailbox Replication Service. The user must be prepared in the target tenant. Before the move, it typically exists as MailUser with the necessary attributes to link it to the source mailbox. After the move. The mailbox is transferred to the destination tenant, and the source object becomes a “MailUser” with a routing address pointing to the new tenant.

This behavior helps maintain mail flow during the coexistence period. Specific license. Native cross-tenant migration currently requires a specific license: Cross Tenant User Data Migration per user, per migration. This license also covers the corresponding native OneDrive migration. Mailboxes on hold. Microsoft states that mailboxes subject to any type of “hold” cannot be migrated using this feature until the underlying issue is resolved.

Content that is moved. The functionality focuses on visible mailbox content, such as: email, calendars, contacts, tasks, and notes. Official reference: Microsoft – Cross-tenant mailbox migration.

Cross-tenant migration for OneDrive

Microsoft also offers a native cross-tenant migration for OneDrive. An important distinction. This operation is a move rather than a traditional pre-migration tool that performs multiple delta syncs. Microsoft specifies that: incremental or delta passes cannot be performed. Redirect. When the move is complete, Microsoft leaves a redirect at the original location so that certain old links can lead to the new OneDrive.

Implication for the project. We should not design the native OneDrive migration using this pattern: pre-migration today → delta tomorrow → final delta. That model might exist in third-party tools, but it is not how the native cross-tenant migration—as documented by Microsoft—behaves. Official reference: Microsoft – Cross-tenant OneDrive migration.

Cross-tenant migration for SharePoint

Another important update is the native capability for Cross-tenant SharePoint migration. It allows for moving SharePoint sites between tenants using SharePoint Online PowerShell. Supported sites. Microsoft documents support for: modern sites, communication sites, classic sites, sites connected to Microsoft 365 Groups, and sites associated with Teams. However, be careful regarding Teams. The fact that we can move a Team’s SharePoint site does not mean that we are migrating the entire Team..

Microsoft makes it clear that this feature moves SharePoint content, but not: the Teams structure, its channels, or any other content specific to Teams. Identity mapping. Before migrating, it is necessary to create a mapping between the users and groups in the source tenant and their equivalents in the destination tenant. This allows for the correct reconstruction of permissions and ownership. The destination site must not already exist.

This functionality is not designed to merge content into an existing site. If the destination site already exists, the move operation may fail. Relevant current limits.

Redirects. After the move, compatible shared links can be redirected to the new location. Power Apps, Power Automate, and extensions. It should not be assumed that a SharePoint content migration will automatically recreate: Power Apps, Power Automate, custom applications, external web parts, or legacy workflows. These dependencies must be inventoried and handled separately. Official reference: Microsoft – Cross-tenant SharePoint migration.

Choosing a coexistence strategy

Not all organizations need to implement every feature we have covered.

The shorter the coexistence period, the better. This is not because a multi-tenant architecture is inherently bad, but because maintaining the following simultaneously: routing, guest users, synchronization, aliases, temporary domains, cross-tenant permissions, and duplicate licenses leads to an incremental increase in complexity. If the ultimate goal is a single tenant, we should move toward that state.

How to approach a coexistence project, step by step

Phase 1: Discovery. Before configuring anything, we must understand both tenants.

Phase 2: Define the end state. A coexistence scenario cannot be designed if we do not know where we want to end up. For each workload, we must decide: whether it will be migrated, remain as is, be recreated, or be retired. Phase 3: Define the coexistence period. Next, we determine: the expected duration, affected users, which services require coexistence, the user experience to be provided, and the limitations that will need to be communicated. Phase 4: Prepare identity.

We configure: B2B, cross-tenant access, synchronization, or Multitenant Organization —but only if necessary. Phase 5: Prepare Exchange. We design: routing, technical domains, connectors, free/busy information, and cutover. Phase 6: Prepare for collaboration. We validate: Teams, SharePoint, OneDrive, and applications. Phase 7: Pilot. A pilot should include real users with different profiles. It is not enough to simply verify that the migration job completes successfully. Pilot testing.

Phase 8: Waves. Once the pilot is validated, we proceed with migration in batches. Each batch should follow this process: Pre-check → migration → validation → support → closure. Phase 9: Removing coexistence. This step must be part of the plan from the very beginning. We review and remove: temporary routing, unnecessary technical domains, legacy MailUsers (when no longer required), temporary guest accounts, unnecessary cross-tenant synchronization, temporary shared channels, organization relationships, connectors, Conditional Access exceptions, and duplicate licenses.

Operations during coexistence

When a migration spans several weeks, coexistence is no longer just a design element; it becomes a service that must be actively managed. What to monitor.

A single channel for incidents. Users should not need to know: “this issue belongs to the source tenant team, and that one to the destination tenant team.” Support should have a single process capable of internally escalating to the appropriate team. Documenting exceptions. If we need to create a temporary exception during a migration wave, we record:

Common mistakes in a tenant-to-tenant coexistence

Technical checklist for cross-tenant coexistence

Frequently asked questions about Microsoft 365 cross-tenant coexistence

Does coexistence between tenants mean merging their users and data?

Coexistence enables specific collaborative relationships between environments that remain independent. It does not, by itself, move mailboxes, documents, or configurations to the other tenant. The project must distinguish between capabilities enabled during the transition and information to be migrated later, so as not to confuse access to a resource with full integration.

Is enabling guest users sufficient?

Guest access can address some requirements, but each collaboration scenario has its own specific needs. Email, calendar availability, documents, and communication channels do not necessarily rely on the same mechanisms. You must identify the workflows the company requires, review the policies of both parties, and test them using representative accounts before rolling them out more broadly.

How is email tested during a phased (batch) migration?

Internal and external messages are verified for users remaining in the source environment as well as those already working in the destination environment. Testing covers replies, alternative addresses, and relevant shared recipients. It must be clear where each message is delivered, and steps must be taken to ensure that temporary configurations do not cause loops or result in unresolved recipients.

What should be reviewed when the coexistence phase ends?

Identify any access relationships, external users, groups, or temporary configurations that are no longer needed. Before removal, the owner of each resource must confirm that their users can continue working from the final, target environment. Any exceptions that remain must be justified, assigned to a designated owner, and scheduled for future review.

Final recommendations: effective coexistence makes migration appear much simpler than it actually is

The Coexistence between Microsoft 365 tenants This is not simply a matter of toggling an option to join two organizations; it is the result of coordinating several distinct layers. Identity management can be handled via B2B, cross-tenant access settings, and—where applicable—cross-tenant synchronization. If multiple tenants belong permanently to the same organization, the “Multitenant Organization” feature provides specific capabilities to enhance collaboration. Email, meanwhile, requires its own dedicated routing design.

While some users remain in the source environment and others are already in the destination, Exchange must know the actual location of each person’s mailbox. The calendar is another independent component. Organization Relationships can provide free/busy information and certain details, but they do not migrate calendars, nor do they automatically resolve room mailboxes or delegate access. Teams also involves various models.

External access, guest access, and shared channels address different needs. B2B direct connect can offer a particularly convenient experience for shared channels, but it should not be confused with a migration. The same applies to SharePoint and OneDrive. External access can allow users to continue working while data migration is being prepared, but temporary permissions must be governed just like any other enterprise access.

Furthermore, overarching all these elements is a constraint that shapes the entire project: a single custom domain cannot be verified in two different tenants simultaneously. For this reason, the transfer of a domain remains one of the most critical stages in any tenant-to-tenant migration. Microsoft’s native migration tools have evolved significantly. As of 2026, we have access to cross-tenant mailbox migration, OneDrive migration, SharePoint migration, and Migration Orchestrator to coordinate specific workloads.

However, there is still no single function that can automatically transform one entire tenant into an identical copy of another. Teams, SharePoint, applications, the Power Platform, permissions, domains, devices, and security all require specific analysis. Therefore, a sound strategy should address five key questions before the project begins: which users will coexist and for how long; what do they need to share; which workloads will be migrated in each phase; and how will all temporary configurations be removed once the project is complete?

If these answers are clear, coexistence ceases to be a collection of stopgap measures and becomes what it should be: a temporary architecture designed to allow the organization to continue working while the underlying Microsoft 365 environment evolves.

Recommended official documentation

Cross-tenant collaboration.

• Microsoft – Microsoft 365 inter-tenant collaboration
• Microsoft – Cross-tenant access overview
• Microsoft – Cross-tenant access settings for B2B collaboration

Cross-tenant synchronization and Multitenant Organization.

• Microsoft – Cross-tenant synchronization
• Microsoft – Multitenant Organization
• Microsoft – Multitenant Organization identity provisioning for Microsoft 365

Teams and B2B direct connect.

• Microsoft – B2B direct connect
• Microsoft – Configure B2B direct connect
• Microsoft – Shared channels in Microsoft Teams

Exchange Online and calendars.

• Microsoft – Create an Organization Relationship
• Microsoft PowerShell – New-OrganizationRelationship

Domains.

• Microsoft – Add and verify custom domains
• Microsoft – Remove a domain
• Microsoft – Add a custom domain to Microsoft 365

Tenant-to-tenant migration.

• Microsoft – Plan a Microsoft 365 tenant-to-tenant migration
• Microsoft – Migration Orchestrator
• Microsoft – Cross-tenant mailbox migration
• Microsoft – Cross-tenant OneDrive migration
• Microsoft – Cross-tenant SharePoint migration
• Microsoft – FastTrack cross-tenant migration