Microsoft 365 Tenant-to-Tenant Migration Services

TRUSTED BY

A Microsoft 365 tenant-to-tenant migration is an identity and business-continuity project before it is a data-transfer project. Calance Microsoft 365 tenant-to-tenant migration services cover the full path from tenant assessment and identity mapping through Exchange Online, OneDrive, SharePoint, Teams, Intune, and Power Platform migration, coexistence during the transition, cutover, and post-migration support. The result is a single, governed tenant that users can work in from the first day, with mail flow, calendars, permissions, and devices behaving as they did before the move.

Mergers, acquisitions, divestitures, and multi-tenant consolidations each put the migration on a business timeline that rarely bends to technical convenience, so planning starts with the deadline and works back to the sequencing that can meet it. Where the need is a broader workplace program, licensing review, or long-term managed support, our Microsoft 365 services cover that ground; the work below concerns moving an existing tenant's users and content into another tenant.

Common Scenarios That Lead to a Tenant Migration

Each scenario changes who owns the target tenant, whether the source stays live, and when domains can transfer, so the scenario is confirmed before any design work begins.

Merger or Acquisition

The acquired organization's users and content move into the acquirer's tenant on the integration plan's timeline. Domain transfer timing, target licensing availability, and the date acquired email addresses change shape every downstream decision.

Divestiture or Spin-Off

A subset of users leaves for a new or third-party tenant while the rest stay. Scope covers who goes and which shared content they take, while holds, retention, and records often remain with the source organization.

Hypercare SupportMulti-Tenant Consolidation

Organizations that accumulated tenants through past acquisitions bring them into one, usually to reduce licensing cost and simplify security administration. Consolidation runs as a sequence of smaller migration costs with own identity mapping, against one target design.

Internal Reorganization or Rebranding

A new corporate identity or restructured business requires new domains, a new tenant name, or different ownership. Users stay the same people, so the task is keeping access, devices, and collaboration history intact while identity changes underneath them.

What Calance's Tenant-to-Tenant Migration Services Cover

Engagements usually draw on most of the areas below, since a tenant migration touches every workload a user depends on, though the depth in each varies with what the source tenant actually contains.

Tenant Assessment and Migration Readiness

Assessment inventories users, licenses, mailbox and archive sizes, OneDrive and SharePoint volumes, Teams structure, Intune enrollment, Power Platform assets, and compliance holds. Findings establish scope, the objects that will block a move, and throughput, so timelines rest on measured data.

Identity Strategy and Microsoft Entra ID Mapping

Identity decisions precede content moves: whether users keep their user principal name (UPN), how domains transfer, how source and target objects map, and whether cross-tenant synchronization bridges the transition. Native tooling moves content, not identities, so target accounts are provisioned separately.

Exchange Online Mailbox Migration

Mailboxes, online archives, shared and resource mailboxes, and distribution groups move with mail routing intact throughout. Mailboxes under hold are identified early because native cross-tenant moves block them, and public folders and transport rules are handled as distinct objects.

OneDrive and SharePoint Online Migration

Personal OneDrive content moves with sharing links redirected, while SharePoint sites, libraries, lists, permissions, and metadata move as shared assets with their own sequencing. Site structure is reviewed first, and our SharePoint consulting services cover redesign where restructuring is wanted.

Microsoft Teams Migration

Teams, channels, conversations, files, tabs, apps, and membership move as shared workloads, while chats and meetings move per user. Teams content depends on Exchange mailboxes, so sequencing follows that dependency, and users learn which history appears in the target.

Intune, Devices, and Endpoint Re-Enrollment

Devices joined to the source tenant must be re-enrolled in the target, so Windows Autopilot profiles, Intune compliance and configuration policies, application deployments, and Conditional Access are rebuilt before the first user cuts over, drawing on our Microsoft Intune services.

Power Platform, Workflow, and Line-of-Business Reconnection

Power Apps, Power Automate flows, Power BI workspaces, and Microsoft 365 Groups carry connections and licensing that do not migrate. Each asset is inventoried, re-authenticated in the target, and retested against ERP and project systems with our integration solutions team.

Security, Compliance, and Microsoft Purview Carry-Over

Retention policies, sensitivity labels, DLP rules, eDiscovery cases, and holds are rebuilt in the target and reconciled against the source, since none travel with content. Defender policies, conditional access, and privileged roles are redesigned so security posture carries over deliberately.

Choosing a Migration Model

The migration model is decided before any tool is selected, because the model determines how long users live in two tenants, how much coexistence infrastructure is needed, and whether a rollback path exists after cutover. Three models cover most enterprise situations, and the choice follows user count, deadline, and tolerance for a transition period rather than a fixed preference.

Single-Event Cutover

All users and workloads move in one coordinated window, typically over a weekend, with MX records and domains switching at the end

Smaller organizations, simple estates, or hard deadlines where a coexistence period is not worth building

Throughput must complete within the window, and rollback after the domain switch is costly

Phased Migration

Users move in batches over weeks or months while both tenants stay live, with mail routing, free/busy, and Teams federation bridging the gap

Larger enterprises, multi-region estates, or any migration where business units must cut over on different dates

Coexistence setup is a project in itself, and users work across two tenants until their batch completes

Tenant Split

A defined subset of users and content leaves for a new or third-party tenant while the rest of the organization stays in the source

Divestitures and spin-offs, where the departing entity needs its own tenant and the remaining entity keeps its obligations

Shared content ownership must be decided per site and per team, and the source tenant retains holds and records for users who have left

Configure MX records, connectors, and accepted domains so mail routes to both tenants
Convert source mailboxes to mail users with a target routing address after each batch
Synchronize the global address list so users see colleagues from either tenant in Outlook

Enable free/busy sharing between tenants through organization relationships
Configure Teams federation and cross-tenant access settings for chat, calls, and presence
Re-grant shared and delegated calendars in the target, since delegation does not migrate

Grant B2B guest access so migrated users still reach source sites not yet moved
Review shared channels and external sharing so partner collaboration is not interrupted
Agree a dated coexistence end point, after which bridging settings are removed

Native Microsoft Tooling vs. Third-Party Migration Platforms

Microsoft provides native cross-tenant migration capabilities, and a mature set of partner platforms covers what those capabilities leave out. Neither is the right answer for every workload, so tooling is recommended per workload after assessment, and the reasoning is documented so the choice can be revisited if scope changes.

Microsoft Migration Orchestrator and cross-tenant tools

Exchange mailboxes, OneDrive, Teams chats and meetings in coordinated batches; separate cross-tenant SharePoint migration

Moves content, not identities; does not migrate shared Teams or channels; blocks mailboxes on hold; no delta passes for OneDrive; requires a per-user Cross Tenant User Data Migration license

Estates where the supported workloads are the whole scope and the organization wants to stay inside Microsoft tooling and licensing

Hybrid of both

Native tooling for workloads it supports well, third-party tooling for the rest

Two consoles, two sets of logs, and two support paths to coordinate

Organizations that want to use licensing already owned without accepting native gaps on shared content

Tenant Split

A defined subset of users and content leaves for a new or third-party tenant while the rest of the organization stays in the source

Divestitures and spin-offs, where the departing entity needs its own tenant and the remaining entity keeps its obligations

Shared content ownership must be decided per site and per team, and the source tenant retains holds and records for users who have left

How Identity, Security, and Compliance Are Handled

Moving data between tenants does not carry security posture with it. Conditional Access rules, multifactor authentication (MFA) registrations, sensitivity labels, retention policies, and privileged roles belong to the tenant rather than the content, so each is redesigned for the target and validated before the first production batch. Organizations under HIPAA or GDPR obligations involve legal and compliance teams first, and a wider posture review is available through our cybersecurity services.

Identity and Access

Provision target accounts, groups, and licenses and verify against the identity mapping
Guide users through re-registering MFA, password reset, and passwordless methods
Rebuild Conditional Access, privileged roles, and admin units under least privilege

Data Protection

Recreate sensitivity labels and encryption settings, then test that labeled content opens
Map DLP and retention policies from source to target and document any gaps for sign-off
Catalog every mailbox and site under legal hold and record a disposition for each

Audit and Accountability

Retain migration logs from every batch as a chain-of-custody record of what moved and when
Keep the source tenant for an agreed window so audit history and rollback stay available
Assign named ownership for the target tenant's security configuration at handover

Workload-by-Workload Migration Considerations

Every Microsoft 365 workload moves differently, and the items that cause post-cutover tickets are usually the ones assumed to travel with the user. The table below sets out what moves and what needs deliberate handling for each workload in a typical enterprise tenant.

Exchange Online mailboxes

Email, calendar, contacts, tasks, notes, folder structure, and rules

Mailboxes on hold are blocked by native tooling; delegation, send-as, and shared mailbox permissions must be re-granted; source mailbox is deleted after a native move

Online archives and public folders

Archive mailbox content; public folder hierarchy and items

Archives often exceed primary mailbox size and dominate throughput; public folders need a separate migration path and mail-enabled folder re-addressing

OneDrive for Business

Files, folders, version history, and sharing links

Native tooling allows no delta pass, so content must be frozen or migrated with a third-party tool; sharing links to external users are re-issued

SharePoint Online

Sites, document libraries, lists, pages, permissions, metadata, and site structure

Hub associations, custom columns, workflows, Power Apps forms, and site-level retention must be rebuilt; unused sites are retired rather than moved

Microsoft Teams (shared)

Teams, standard channels, private and shared channels, channel messages, files, tabs, and membership

Native tooling does not migrate shared Teams content; private channels have their own SharePoint sites; third-party apps and bots need re-registration

Microsoft Teams (per user)

One-to-one and group chats, meetings, and meeting recordings

Chat migration depends on mailbox migration; participant lists change where some members have not migrated; duplicate threads can appear in both tenants

Microsoft 365 Groups and distribution lists

Group membership, group mailbox, and associated SharePoint site

Dynamic membership rules reference source attributes and must be rewritten; nested groups and mail-enabled security groups are recreated by object type

Microsoft Intune and devices

Device records, compliance and configuration policies, app deployments, Autopilot profiles

Devices must be unenrolled and re-enrolled; BitLocker keys, LAPS passwords, and certificates are re-escrowed; Conditional Access is rebuilt in the target

Power Platform

Power Apps, Power Automate flows, Power BI workspaces, semantic models, and dataflows

Connections and credentials must be re-authenticated; premium licensing re-assigned; row-level security and gateway configurations rebuilt

Planner, Loop, and Viva

Plans, tasks, Loop workspaces and components, Viva Engage communities

Tool coverage varies by product; Loop and Viva content may require export and recreation; plan ownership follows Microsoft 365 Group migration

Microsoft Purview and compliance

Retention policies, sensitivity labels, DLP rules, eDiscovery cases, holds, and audit history

None move automatically; policies are rebuilt and reconciled; audit log continuity requires the source tenant to be retained for the required period

Microsoft 365 Copilot

Licensing and Copilot-related settings

Licenses are reassigned in the target; prior interaction history does not migrate; permission hygiene in the target affects what Copilot can surface

Domains and DNS

Custom domains, MX, SPF, DKIM, DMARC, and Autodiscover records

A domain can exist in only one tenant at a time, so removal from the source and verification in the target is a timed cutover step with its own rollback plan

Tenant-to-Tenant Migration Process

Delivery runs through six stages with a governance gate between each, so the business confirms readiness before users are affected. Identity and coexistence work runs ahead of content migration, and the pilot is treated as a rehearsal of cutover rather than a test of the tool.

Discovery and Tenant Assessment

Inventory users, licenses, mailboxes, archives, OneDrive, SharePoint, Teams, and devices
Identify blockers such as held mailboxes, oversized archives, and unsupported workloads
Confirm the business deadline, downtime tolerance, and regulatory obligations

Identity and Domain Strategy

Decide UPN treatment, domain transfer sequence, and source-to-target identity mapping
Provision target accounts, groups, licenses, and admin roles, then validate the mapping
Design Conditional Access, MFA, and device enrollment for the target before anyone moves

Migration Design and Coexistence Setup

Select the migration model and tooling per workload, documenting the reasoning for each
Configure mail routing, directory sync, free/busy, and Teams federation between tenants
Define migration waves by business unit or dependency, with entry and exit criteria

Pilot Migration

Migrate a pilot group representing every device type, role, and workload combination
Validate mail, calendars, file access, Teams history, and sign-in from the user's seat
Review pilot findings at a governance gate and adjust wave plans and user communications

Wave Migration and Cutover

Run production waves with pre-staging and delta passes, keeping each within its window
Execute domain and MX cutover against a timed runbook with owners and rollback triggers
Provide elevated support during each cutover, with 24/7 coverage during the domain switch

Decommissioning, Optimization, and Support

Reconcile migrated content against source inventories and record every exception
Remove coexistence settings, reclaim licenses, and decommission the source tenant
Hand over documentation and ownership, with support through our IT help desk services

Discuss Your Migration Plan

Manufacturing and Automotive

Plant-floor and dealer systems often authenticate against the tenant directory, so identity cutover is sequenced around production shifts and dealer portal access rather than office hours. Shared shop-floor devices are re-enrolled per shift.

Healthcare

Clinical and administrative users operate under HIPAA obligations, making audit log continuity, retention carry-over, and shared-device re-enrollment architectural requirements rather than cleanup tasks. Clinical application sign-in is validated in the pilot before any care team moves.

Life Sciences

Validated environments and long retention periods mean migration records become part of the compliance file, so chain-of-custody logs and change documentation are produced to a standard auditors can accept. Validated systems are migrated under controlled change management.

Financial Services

Litigation holds, eDiscovery cases, and regulatory notification requirements are cataloged before design, since held mailboxes block native moves and some records cannot leave the source tenant. Legal sign-off is recorded for each affected mailbox.

Construction and Engineering

Project control platforms such as Procore, PMWeb, and CMiC are tied to user identity and SharePoint libraries, so reconnection is planned with our construction software integration team to keep active projects uninterrupted.

Why Calance for Tenant-to-Tenant Migration

Choosing a migration partner comes down to four questions: whether identity and coexistence are designed before data moves, how much experience sits behind the SharePoint, Teams, and Exchange work, how well the partner understands the wider Microsoft environment, and who stays accountable after cutover. The points below answer each from how our practice is arranged.

Identity and Coexistence Planned Before Data Moves

Engagements begin with identity mapping, domain strategy, and coexistence design, because those decisions determine whether users can work normally during the transition. Content migration is scheduled only once target accounts, licenses, and bridging configurations are validated.

Migration Experience Across SharePoint, Teams, and Exchange

Our team has delivered SharePoint migrations supporting a commercial bank merger, 20+ years of SharePoint work for Isuzu, and ongoing migrations for Wellpath. Shared content is where tenant migrations most often lose time, and that experience is applied directly.

Full Microsoft Ecosystem Context

As a Microsoft Solutions Partner for Modern Work and Security with 20+ years on the platform, Calance works across Entra ID, Intune, Purview, Defender, and Azure, so identity, device, and security decisions are made within one Microsoft cloud consulting practice.

Ownership That Continues After Cutover

A 90% client retention rate reflects how we work once migration is complete. Onshore architects lead design and governance, offshore engineering runs waves overnight, and follow-the-sun support covers cutover windows, so the people who planned the migration stay accountable.

What does a Microsoft 365 tenant-to-tenant migration involve?

A tenant-to-tenant migration moves users, mailboxes, files, Teams, devices, and applications from one Microsoft 365 tenant into another after a merger, acquisition, divestiture, or consolidation. Scope covers identity mapping, workload migration, coexistence, domain cutover, and rebuilding security in the target.

Will users keep their existing email addresses?

Usually yes, if the custom domain transfers to the target tenant. A domain can exist in only one tenant at a time, so the transfer is a timed cutover step, and users work under a temporary address until it completes.

What happens to the source tenant after migration?

The source tenant is normally retained for a defined window, often 30 to 90 days, so audit history, eDiscovery, and rollback remain available. After reconciliation and sign-off, coexistence settings are removed, licenses reclaimed, and the tenant decommissioned.

How long does a tenant-to-tenant migration take?

Small single-event cutovers can complete in a few weeks, while phased enterprise migrations run three to six months or longer. Duration depends on user count, data volume, SharePoint and Teams complexity, device re-enrollment scope, and holds that block native tooling.

Can users keep working during the migration?

Yes, with a phased model and coexistence in place. Mail routing, free/busy sharing, and Teams federation let migrated and unmigrated users collaborate while batches move. Each user sees a cutover window, overnight or over a weekend, and re-registers multifactor authentication.

How are Teams chats and channels handled?

Shared Teams, channels, files, and tabs move as team-level assets, while one-to-one and group chats and meetings move per user. Native Microsoft tooling does not migrate shared Teams content, so third-party platforms are generally used for channel content.

Can mailboxes under litigation hold be migrated?

Not with Microsoft's native cross-tenant tooling, which blocks held mailboxes. Options include migrating them with a third-party platform that preserves hold content, exporting held data, or keeping the source tenant live until the hold lapses, with legal sign-off recorded.

What happens to guest users and external sharing?

Guest accounts in the source do not move; they are re-invited to the target where collaboration continues. External sharing links on OneDrive and SharePoint are re-issued after migration, and cross-tenant access settings are reviewed so partner collaboration is not interrupted.

Do Intune-managed devices need to be re-enrolled?

Yes. Devices joined to the source tenant must be unenrolled and re-enrolled in the target, with Autopilot profiles, compliance policies, and application deployments rebuilt beforehand. BitLocker keys and certificates are re-escrowed, and re-enrollment is scheduled with each user's batch.

What happens to Power Automate flows and Power BI reports?

Power Apps, flows, Power BI workspaces, and dataflows are inventoried and recreated in the target, then re-authenticated, since connections are tenant-specific. Premium licensing is reassigned, gateways rebuilt, and each ERP or project-system integration retested before its owner signs off.

How Much Does a Tenant-to-Tenant Migration Cost?

Cost depends on user count, data volume, workloads in scope, whether third-party tooling is required, device re-enrollment scope, compliance complexity, and coexistence duration. Calance scopes each engagement after the tenant assessment so the proposal reflects the measured estate rather than assumptions.

Should We Use Microsoft's Native Tools or a Third-Party Platform?

Native tooling suits estates where mailboxes, OneDrive, and per-user Teams content are the whole scope. Third-party platforms are recommended for shared Teams content, held mailboxes, delta synchronization, or coexistence features. Calance recommends per workload after assessment and is platform-neutral.

What Does Our Organization Need to Provide?

Clients provide administrator access to both tenants, a named owner per workload, decisions on identity and domain treatment, legal sign-off on holds and retention, a user communications channel, and availability for governance reviews. Calance supplies assessment, design, execution, and documentation.

Can the Migration Be Rolled Back?

Partially, depending on model and tooling. Third-party platforms copy content and leave the source intact, so users can be redirected back by reverting MX records. Native mailbox moves delete the source mailbox, which limits rollback. Calance defines rollback triggers per wave.

What Support Is Available After Cutover?

Elevated support runs through each cutover window and a stabilization period afterward, with 24/7 coverage during the main domain switch where required. After stabilization, support can stay with your team, transfer to Calance through co-managed IT services, or be shared.