Moving Between Microsoft 365 Tenants: What Businesses Need to Plan

When two organisations both use Microsoft 365, it is tempting to assume that bringing them together — or splitting them apart — should be straightforward. Same platform, same tools, same cloud. How hard can it be?

In practice, moving between Microsoft 365 tenants is one of the more involved projects a business can take on. The data usually can move. But the identities, domains, security settings, applications, permissions and working habits built around that data do not move by themselves — and they are what determine whether the business keeps working on the other side.

This article explains why organisations migrate between tenants, what actually moves, and what needs planning. If you are already scoping a project, our Microsoft 365 Tenant-to-Tenant Migration service covers how Altitude manages the whole transition.

Why Organisations Migrate Between Tenants

Common triggers include:

• Mergers and acquisitions. One business buys another, and everyone needs to end up in a single environment.
• Company separations and divestitures. Part of a business is sold or split off and needs its own tenant, users and data.
• Consolidation. Years of growth or previous acquisitions have left multiple tenants that are expensive and confusing to run.
• Changing provider or partner. A business wants to leave a tenant controlled by a previous IT provider or reseller and regain direct control.
• Rebranding. A new business name and domain sometimes prompts a wider restructure of the Microsoft environment.

Whatever the trigger, the same principle applies: a tenant migration is a business transition project — not simply a mailbox migration.

What a Microsoft 365 Tenant Really Is

A tenant is not just a collection of mailboxes. It is the complete container for an organisation's Microsoft cloud presence: the Microsoft Entra ID directory of users, groups and administrator roles; registered domains; Exchange Online; SharePoint sites; Teams; OneDrive accounts; security policies such as MFA and Conditional Access; device management; compliance and retention settings; app registrations; and the licensing agreements attached to it all.

Two tenants — even in similar businesses — almost always contain different identities, security baselines, domains, applications, site structures, Teams, permissions, devices and compliance settings. The migration has to reconcile all of that, not just copy files.

What Migration Tools Can Move

Microsoft provides supported migration routes for core workloads, and cross-tenant capabilities have improved in recent years. Broadly, with the right planning, licensing and configuration:

• Mailboxes can be moved between tenants using supported cross-tenant mailbox migration methods.
• OneDrive content can be migrated once users are mapped between tenants.
• SharePoint sites and content can be migrated with the destination structure designed first.
• Teams structures and their underlying SharePoint content can be moved; some elements, such as certain chat history, apps and tabs, may need third-party tooling, rebuilding or archiving.

What no tool does automatically: recreate your security configuration, re-register applications, re-enrol devices, rebuild permissions sensibly, or update the third-party systems that authenticate against the old tenant. Those are project workstreams in their own right.

Identity Mapping Comes First

Every workload migration depends on identity. Each user, group and shared resource in the source tenant needs a correctly configured counterpart in the target — with the right name, licence, group memberships and administrator protections. Get the mapping wrong and mailboxes land in the wrong place, permissions break, and files lose their owners.

Identity work also includes deciding what not to move: leavers, stale accounts, unused groups and historic shared mailboxes are better dealt with before migration than copied into the new environment.

Domains Can Only Live in One Tenant

A custom domain can only be registered in one Microsoft 365 tenant at a time. Moving it means removing it from the source and adding it to the target — a step that touches sign-in names, email addresses, mail flow and DNS all at once.

The domain cutover has to be sequenced carefully around MX records, Autodiscover and email authentication (SPF, DKIM and DMARC) so that mail keeps flowing and deliverability is protected. It is usually the most sensitive moment of the entire project.

Exchange, OneDrive, SharePoint and Teams

Exchange Online. Mailbox moves are well supported, but delegates, shared mailboxes, send-as permissions, calendar sharing and mail-enabled applications all need reviewing — they rarely survive the move untouched.

OneDrive. Files move; sharing links generally change. Staff need to know which links to re-share after cutover.

SharePoint. The temptation is to copy everything as-is. A migration is the best opportunity you will get to redesign the structure — moving years of accumulated clutter into a new tenant simply relocates the disorder.

Teams. Team and channel structures can be recreated or migrated, and files come across via SharePoint. Chat history, third-party app integrations and tabs need individual decisions: migrate, archive or let go.

Applications and Devices

Applications are the most commonly underestimated workstream. Line-of-business systems, app registrations, single sign-on configurations, integrations and add-ons frequently authenticate against the old tenant. Each one must be found during discovery and reconfigured — otherwise staff discover the breakage after cutover, one system at a time.

Devices matter too. Machines joined or enrolled to the source tenant typically need to be moved to the target's management, and users will sign in with new credentials and re-register MFA. Planned properly, this is a communicated, supported step rather than a surprise.

Security and Compliance

Security settings do not migrate. MFA registrations, Conditional Access policies, administrator roles, Intune configuration, external sharing controls, audit settings, retention policies and legal holds all have to be deliberately designed and configured in the target tenant — ideally before business data arrives.

Handled well, this is an opportunity: consolidating tenants is a natural moment to standardise security across the whole organisation rather than inheriting the weaker of two baselines. Compliance obligations — retention, eDiscovery, legal hold — need specific attention, because data being moved between tenants can affect where and how it is preserved.

Pilot First, Validate Always

Well-run migrations move a small, representative group of users first. The pilot proves the identity mapping, migration tooling, device experience and application access before the whole organisation follows — and surfaces the problems while they are still cheap to fix.

Validation is the other non-negotiable. After each phase, email, files, Teams, applications, permissions, devices and backup are checked against agreed criteria. The source tenant is reduced or closed only after validation is complete and the business has signed it off — never immediately after cutover.

Common Mistakes

• Treating it as a mailbox project. Mail is often the easiest workload; applications and identity are usually the hardest.
• Skipping discovery. Dependencies you did not find become outages you did not plan for.
• Copying permissions blindly. Historic over-sharing should be fixed in transit, not replicated.
• Underestimating the domain move. The one-tenant-at-a-time rule forces a real cutover that must be sequenced precisely.
• Closing the source tenant too early. The old tenant is the safety net until everything is validated.
• Forgetting the people. New sign-ins, new MFA, changed links and changed habits need communication and support, not just a technical runbook.

How Altitude Manages Tenant Migrations

Altitude approaches tenant-to-tenant migration as a consultancy-led business transition, following our Measure • Understand • Improve • Maintain framework:

• Measure. Discovery across both tenants — users, mailboxes, SharePoint, Teams, OneDrive, applications, devices, security, compliance, licences and domains.
• Understand. Dependency analysis, risk identification, unsupported workloads, migration sequencing and the business priorities that shape them.
• Improve. Target tenant preparation — security, MFA, Conditional Access, administrator accounts, licensing and backup — followed by controlled, piloted migration phases and validation.
• Maintain. Ongoing Operational Heartbeat reviews so the consolidated environment stays secure and well managed after the project ends.

What clients are really buying is certainty: planning, business continuity, security, documentation and risk reduction — not simply a data copy.

If your business is planning a merger, separation, consolidation or provider change, start with the Microsoft 365 Tenant-to-Tenant Migration service — including a discovery assessment that maps both environments and produces a realistic roadmap before you commit.