Microsoft 365 Tenant-to-Tenant Migration

It is the move of one organization's Microsoft 365 estate — identities, mailboxes, OneDrive and SharePoint content, Teams, groups, archives, Viva Engage, Power Platform and the email domain — from one Microsoft 365 tenant into another. Microsoft has no operation that moves a tenant, so the work is a program: inventory both tenants, re-provision identity in the target, move each workload with Microsoft's native cross-tenant feature or a migration tool, rebuild what cannot move, cut the domain over in one planned window, and support users on the other side. The usual triggers are a merger or acquisition, a divestiture, a rebrand, a move between regions, or leaving a reseller-controlled tenant.

Yes. Office 365 is the former name of most of the plans now sold as Microsoft 365, and Office 365 E1, E3 and E5 are still sold under that name, so an Office 365 tenant-to-tenant migration and a Microsoft 365 tenant-to-tenant migration are the same program on the same tenants. The plans you hold matter only for licensing: Microsoft's Cross-Tenant User Data Migration add-on is documented as available to Microsoft 365 Business Basic, Standard and Premium, Microsoft 365 F1, F3, E3 and E5, Office 365 F3, E1, E3 and E5, and the standalone Exchange Online, SharePoint and OneDrive plans.

The program is quoted in writing from your inventory, and you pay after you approve delivery. The quote is assembled from the published prices of the workload moves it includes — at the time of writing, cutover email migration at $35 per mailbox + $3,500 tenant fee, OneDrive at $10 per user + $1,500 tenant fee, SharePoint at $100 per site + $2,500 tenant fee, Teams at $3,500 tenant fee + a fee per team, Entra ID at $1,300 for a basic transition or $1,300 + $2 per user staged, shared and group mailboxes at $35 per mailbox + $500 tenant fee each, in-place archives at $10 per mailbox + $800 tenant fee, Viva Engage at $3,500 per project, the MX spooler at $2,890 per project, and device automation at $6 per seat + $4,500 tenant fee — plus the discovery, the plan, the identity and domain work, cutover coordination and post-migration support. Microsoft's licenses and any migrator licenses are yours and sit outside the quote. Standard scope is one source and one target tenant; anything larger is quoted per estate.

About eight weeks is the typical shape for one source and one target tenant: a week of read-only discovery, a week to sign the inventory and fix the plan, two to three weeks of target preparation and pre-staging while people keep working, a pilot wave, one to two weeks of production waves including the domain cutover, and a final week of reconciliation, hypercare and closeout. Small estates finish sooner. The variables that move the date are how quickly decisions are signed, when the Cross-Tenant User Data Migration licenses arrive — Microsoft recommends submitting mailbox batches about two weeks before cutover — whether held mailboxes have a ruling, and how much of SharePoint and Teams has to travel on a tool.

Cutover means everyone moves in one window, usually over a weekend, with mail and files pre-staged beforehand so the window is short; it suits estates where one identity change is acceptable and the domain can move once. Staged means users move in waves over weeks while both tenants keep working, which needs coexistence — mail routing between the tenants, free/busy through an organization relationship, directory presence through Microsoft Entra cross-tenant synchronization or B2B collaboration — and Entra ID P1 for the synchronized users. Staged costs more and lasts longer but keeps the business working across a deal timeline. The inventory and your dates decide it; most single-source migrations under a few hundred users are cutover, most deal-driven ones are staged.

Not if the window is planned and the spooler is in scope. A custom domain can be verified in only one tenant, so there is a window — realistically 30 minutes to three hours, planned at up to 24 hours — in which it belongs to neither tenant and the sending server receives no valid destination. The MX spooler service points MX at a holding service before the window, accepts and queues every inbound message, and releases the queue to the target tenant once the domain is verified there; the no-downtime email migration variant builds the same protection into the mailbox move. Without a spooler, sending servers retry for hours and then bounce, which is the outcome the standard cutover page tells you to plan for.

Three, depending on the path. Native cross-tenant mailbox and OneDrive moves need the Cross-Tenant User Data Migration add-on: a one-time per-user license, assignable on either the source or the target user object, covering both workloads; Microsoft's documentation states that migrations fail without it and that no exceptions are made. Native SharePoint site moves need Cross-Tenant Shared Data Migration licenses, counted per 100 GB moved and documented as available to Enterprise Agreement customers at the time of writing. Coexistence through cross-tenant synchronization or a multitenant organization needs Microsoft Entra ID P1 for the synchronized users. The target tenant also needs its own subscriptions before anyone signs in. All of it is bought by you; we quantify it from the inventory and can quote and provision it as your CSP.

No, and knowing where they stop is most of the plan. Natively, Microsoft moves user and shared mailboxes with their archives, OneDrive accounts, and — for Enterprise Agreement customers — SharePoint sites, each as a one-shot move with no delta pass; its migration orchestrator, in preview at the time of writing, adds Teams chats and meetings alongside the mailbox and OneDrive; and its Power Platform tenant-to-tenant move links production and sandbox Dataverse environments to the destination. Everything else — teams and channels, Microsoft 365 Group mailboxes, Viva Engage, app registrations, Intune and security configuration, retention and sensitivity policies, flows' connections — is rebuilt in the target or carried by a migration tool. The table on this page shows the bucket for each workload.

Teams and channels have no native cross-tenant move. The Teams migration scope recreates every team and channel in the target, transfers the files, restores membership and owners, and carries channel conversation history with supported tooling. Private and group chats are a separate scope: Microsoft's migration orchestrator, in preview at the time of writing, moves chats and meetings together with the user's mailbox, and where it does not fit a third-party tool carries them within its documented limits or they stay searchable in the source. Two things every user is told before their wave: Teams meeting links are invalid in the target and recurring meetings must be re-created by their owners, and tabs, Planner boards, apps and connectors are re-created rather than moved.

Passwords and MFA registrations cannot be exported from a Microsoft Entra ID tenant, so every user receives a temporary password for the target tenant and registers MFA again on their move day; the communications pack and hypercare cover it. Windows devices joined to the source tenant leave it and join the target, re-enroll in Intune and, where Autopilot is used, re-register against the target; on larger estates the device migration automation preserves each user's profile through the rejoin so documents, desktop settings and browser favorites are where they were. Mobile devices re-enroll. Nothing about a device's compliance history in the source tenant comes across; the target's policies apply from the join.

Microsoft's tenant-to-tenant environment move links a production or sandbox Dataverse environment to the destination tenant: the source administrator submits the request, the destination tenant approves it, and the move can take up to 24 hours with the environment in administration mode. Users must exist and be licensed in the destination first, default, developer, trial and Teams environments are not supported, finance and operations add-ins block the move, and application users do not migrate. Afterwards, connections, connection references, custom connectors, gateways and security groups are rebuilt and flows arrive turned off, which is why every flow owner is named in the inventory. App registrations and enterprise applications are tenant objects: each is re-registered in the target with new credentials and consent, re-pointed by its vendor, or retired, and the re-integration work beyond re-registration is quoted separately.

They stop until counsel decides. Microsoft's documentation states that mailboxes on any type of hold are not migrated and the move is blocked, and that OneDrive accounts with a hold policy are blocked as well; the documented path is to release the hold, migrate, and reapply it in the target. Releasing a hold is a legal decision with a preservation obligation attached, so the inventory lists every held object in week one, the options go to your counsel in writing — release and move, retain in the source and grant access, export, or exclude — and the wave plan waits for the instruction rather than working around it. Remember too that after a native mailbox move the source mailbox is no longer accessible, so anything the old tenant must keep is exported before that wave.

Tenant configuration. Conditional Access and security baselines, Intune policies and app assignments, retention policies and labels, sensitivity labels and DLP, mail-flow rules, Teams voice configuration, app registrations and enterprise applications, Power Platform connections and gateways are tenant objects and are re-created in the target from the inventory. Within the workloads that do move, Microsoft documents specific gaps: send-on-behalf and cross-tenant delegate permissions, the Teams chat folder, Outbox items, signatures and Teams meeting links for mailboxes; workflows, apps, Power Apps and flows attached to SharePoint sites; and no second pass for OneDrive or SharePoint. The closeout report lists every deliberate difference between the source and target configuration.

Yes, and there are two ways to do it. If you want to keep your tenant and simply end GoDaddy's control, the GoDaddy defederation service converts the domain to standard Microsoft Entra sign-in, removes GoDaddy's delegated administration and moves billing to a direct CSP relationship without migrating anything. If you want a clean tenant of your own, the GoDaddy email migration is a cutover tenant-to-tenant email migration from the GoDaddy-managed tenant, and the rest of this program applies to the files, Teams and identity around it. The inventory tells us which is cheaper and less disruptive for your estate.

The workload moves are the same; the program layer is not. Bringing two or more tenants together after an acquisition, with a Transition Services Agreement, coexistence for both companies and consolidated licensing and billing, is Microsoft 365 Mergers and Acquisitions Tenant Consolidation. Carving a business unit out of a tenant — a separation register, parent-tenant de-provisioning and a TSA-exit evidence pack — is Microsoft 365 Divestiture and Carve-Out Tenant Separation. Both of those pages sequence the published tenant-to-tenant services this page describes. This page is the end-to-end migration for one source tenant into one target tenant, which is what most mergers, rebrands and reseller exits actually need.

A new sign-in and some rebuilding. They sign in to the target tenant with the new identity and a temporary password, register MFA, and let Outlook rebuild its profile against the new address — Microsoft documents that the local cache downloads again, which is a network-capacity question when a wave lands and is in the plan. Their mail, calendar and contacts are there from the pre-stage and the final pass; their OneDrive files are there with a redirect left at the old location; their teams are there with files and membership. They re-create recurring Teams meetings they own, re-create their signature, and re-share any external links. The communications pack tells them all of this the week before, in plain language, and hypercare answers what the service desk cannot.

It is retired to a plan, not switched off. Once the closeout report is signed, the source tenant keeps running until the decommission plan's preconditions are met: every workload reconciled, exports for anything that must be retained completed, migration endpoints and the organization relationship removed, guest and cross-tenant access settings cleaned up, licenses reclaimed against their renewal dates, and the domains released. Only then, on your written authorization, are the remaining subscriptions canceled and the tenant allowed to lapse. If a reseller controlled the source tenant, cancellation with that reseller is yours to initiate; we tell you exactly when it is safe.

Yes, and the plan is written to make that explicit. Many customers keep the user communications, the desk-side Outlook and device work, the DNS changes at their registrar and the application re-integration with their vendors, and hand us the inventory, the identity and domain design, the workload moves, the domain cutover and the reconciliation. The responsibilities section on this page is the default split; the kickoff adjusts it and the fixed quote reflects what you keep. What we ask is that one decision-maker signs the inventory and each wave, and that the service desk on both sides holds the move-day instructions before a wave starts.