Can Microsoft 365 migration combine multiple tenants?

Multiple Microsoft 365 tenants can be consolidated into a single target tenant, but this is a structured tenant-to-tenant migration rather than a simple data transfer. The work involves deciding how the combined organisation should be represented, preparing the destination environment, moving each workload in a controlled sequence and confirming that access, security and business processes continue to function afterwards.

Start with the target design. Before any migration activity, the organisation should define how the target tenant will be structured. This includes the tenant’s domains, user and group naming conventions, administrative roles, SharePoint and OneDrive architecture, Teams structure, security policies and compliance requirements. Where the source tenants have conflicting settings or duplicated objects, a target design is needed to determine which configuration is retained, amended or replaced.

A useful design should also distinguish between genuine consolidation and simple coexistence. Some organisations need every user, mailbox and workload moved into one tenant. Others may retain selected workloads in a separate environment for regulatory, operational or organisational reasons. Establishing this boundary early prevents unnecessary migration work and makes it clearer which data must be transferred, archived or left in place.

Assess each source tenant separately. A discovery exercise should record users, shared mailboxes, groups, aliases, devices, applications, external sharing links, Teams, SharePoint sites, OneDrive accounts and relevant security settings. It should also identify inactive accounts, duplicate identities, obsolete sites, oversized mailboxes and data with unclear ownership. Migrating everything without this assessment can carry unnecessary clutter and conflicting permissions into the target tenant.

Identity matching is particularly important where the same person exists in more than one tenant or uses different sign-in names across environments. Each source account needs a defined destination identity, and the migration plan should account for guest accounts, service accounts, shared accounts and accounts used by automated processes. Duplicate usernames or email addresses may require temporary naming arrangements before the final identities can be established.

Plan domains and mail flow carefully. A custom domain can generally be associated with only one Microsoft 365 tenant at a time. Moving it therefore requires the relevant users, groups, mailboxes and aliases to be prepared in the destination, followed by removal from the source and verification in the target. DNS changes, mail routing, autodiscover behaviour and mail-enabled objects must be coordinated so that messages are not misdirected during the transition.

Where a single cutover is unsuitable, temporary routing and coexistence arrangements may allow users in different tenants to communicate while migration takes place. These arrangements need testing because directory visibility, free/busy information, external sharing and meeting invitations may not behave in the same way as they do within one tenant. The coexistence period should have a defined end point rather than becoming a permanent substitute for the target design.

Move workloads according to their dependencies. Exchange Online mailboxes, OneDrive, SharePoint, Teams and other Microsoft 365 data do not all migrate in the same way. Mailbox content may require pre-migration synchronisation followed by a final cutover. OneDrive and SharePoint migrations need attention to file ownership, sharing links, version history, metadata and permission inheritance. Teams can involve conversations, files, membership, channels, meeting information and connected SharePoint locations, so the expected result should be documented for each workload rather than assuming that all content transfers identically.

Applications and integrations should be mapped to the new tenant before users are moved. Examples include email-enabled systems, document management tools, backup services, line-of-business applications, monitoring platforms and automation using Microsoft 365 identities. An application may rely on a tenant identifier, an app registration, an application permission, a mailbox or a specific SharePoint location. These dependencies can fail even when the associated user data has migrated successfully.

Use staged migration where it reduces risk. A pilot group should represent the different user types, departments, mailbox sizes, device arrangements and application dependencies found in the organisation. The pilot validates the migration method and exposes issues with identity matching, data permissions, mail flow, Teams access and user sign-in before the wider population is affected.

After the pilot, users can be moved in planned batches. Each batch should have entry criteria, an agreed migration window, an ownership record for unresolved issues and clear validation checks. Pre-staging data can reduce the amount of work required during the final transition, but it does not remove the need for a carefully controlled cutover. A migration runbook should state who performs each action, which checks confirm success and what happens if a step fails.

Review security and compliance during consolidation. Tenant consolidation can expose differences in multifactor authentication, conditional access, device compliance, retention, audit logging, data loss prevention and administrative roles. The destination should not simply inherit the least restrictive configuration from the source tenants. Instead, the organisation should compare policies, identify conflicts and apply an agreed baseline that reflects its risk and regulatory obligations.

Permissions also need more than a technical copy. Groups with similar names may have different purposes, and inherited access can change when sites, teams or identities are recreated. After migration, access should be tested using representative user accounts, including standard users, managers, external guests and administrators. Sensitive sites and shared mailboxes deserve specific review because incorrect permissions may not be obvious to the people who created them.

Validate the result, not just the transfer log. A completed migration report confirms that a technical task ran, but it does not prove that users can work normally. Validation should cover sign-in, email sending and receiving, calendar access, shared mailbox use, OneDrive synchronisation, SharePoint permissions, Teams membership, external collaboration and connected applications. Business owners should confirm that critical documents, workflows and records are present and usable.

The source tenants should be retained in a controlled state until validation, reconciliation and any required legal or retention checks are complete. Decommissioning too early can remove evidence needed to investigate missing data or restore an overlooked dependency. Once the organisation has confirmed that the target tenant is authoritative, old accounts, domains, routing rules and licences can be retired according to an agreed decommissioning plan.

A successful multi-tenant migration therefore depends as much on governance and preparation as on the transfer technology. S2 Technology Group can provide planning and technical guidance for organisations assessing tenant consolidation, including the target design, workload sequencing, identity dependencies, validation criteria and post-migration management.