Tenant-to-Tenant M365 Migration Playbook

Tenant-to-tenant Microsoft 365 migration is the hardest type of M365 work. Unlike moving mailboxes from on-prem to cloud — where the destination is greenfield — a tenant-to-tenant migration moves an entire workforce from one cloud identity to another. Mailboxes, OneDrive, SharePoint, Teams, Power Platform, the user identity itself. Often during an M&A integration, where deadlines are non-negotiable and visibility from the executive team is high.

This post is the playbook we use. It assumes you've decided the migration is happening — what we'll cover is the scope, the tooling decisions, the timeline math, and the failure modes that take projects sideways.

Why tenant-to-tenant happens

Three patterns drive most engagements:

• M&A integration — acquired company needs to be folded into the parent company's tenant. Often with a hard "Day 1" or "Day 90" deadline imposed by the deal.
• Divestiture — a business unit is being spun off and needs its own M365 tenant carved out of the parent.
• Rebrand or domain consolidation — the company is changing its primary identity and wants the tenant to match. Less time pressure but often more emotional pressure (CEO is paying attention).

Each pattern has slightly different constraints, but the technical core is the same: move users + data + permissions + collaboration history from Tenant A to Tenant B with minimal disruption.

What's actually being migrated

Mailboxes

Every mail item, every calendar item, every contact, every rule, every category. Plus archive mailboxes if licensed. Plus journal mailboxes if applicable. Plus shared mailboxes (which are surprisingly often forgotten in scoping).

OneDrive content

Every user's OneDrive personal storage. Files, folders, metadata, permissions, sharing links. The total OneDrive footprint is almost always the largest data set in the migration — bigger than mailboxes by 5–20x in our typical engagements.

SharePoint sites

Every site, library, list, page, web part configuration, permission set. Customizations and SPFx components if present. The information architecture has to be re-validated in the destination — what made sense in the source tenant's IA may not fit the destination's.

Microsoft Teams

Teams, channels (standard and private), files in channels (which are SharePoint-backed), 1:1 chats, group chats, meeting recordings, calling configurations, voicemail. This is the scope item that surprises people most often — "Teams data" is actually four different stores under the hood.

Power Platform

Power Apps, Power Automate flows, Power BI workspaces. Connection references and connection credentials. Custom connectors. Environment-level configurations.

Identity and licensing

User accounts, groups (security and Microsoft 365), licensing assignments, Conditional Access policies, MFA registrations, app registrations, service principals.

External-facing dependencies

Custom domains, DNS records (MX, SPF, DKIM, DMARC, autodiscover, SIP, Teams Phone), guest user invitations, B2B relationships.

The phased approach

Phase 1: Discovery (1–3 weeks)

Inventory everything in scope. Get the tenant settings dump. Catalog third-party apps and integrations. Map the user list. Understand the licensing posture in source and destination. Identify unique-snowflake things — odd Power Platform flows that depend on a specific connection, third-party apps with tenant-specific URLs, custom connectors that need to be re-built.

Output: a written scope document with a fixed-fee SOW and a phased timeline. This phase is non-skippable. Projects that skip discovery to "save time" reliably overrun by 2-3x.

Phase 2: Pilot (1–2 weeks)

Select a representative slice — one department, one office, one workload — and migrate it end-to-end. Validates the runbook, surfaces tooling problems on a small surface area, and gives the change-management team a real story to tell users.

Phase 3: Cutover (4–10+ weeks depending on scope)

Full migration. Mailboxes typically migrated in waves of 100–500 at a time. OneDrive and SharePoint done in parallel. Teams and Power Platform on their own track. Identity cutover happens at a defined moment with all stakeholders aware.

The cutover window itself is short — usually a single weekend. Most of the cutover phase is preparation, then a coordinated DNS and identity flip.

Phase 4: Hypercare (2 weeks default)

Post-cutover support. Residual ticket cleanup. Validation that everything actually works in production. Knowledge transfer to the operations team. Final post-mortem.

Tooling decision matrix

Tool	Pricing model	Strongest for	Weakest for
Microsoft native (Cross-Tenant Sync, EAC, SPMT)	Free with M365 licensing	Small organizations; predictable mailbox + OneDrive moves	Teams chat history; granular permissions; large-scale automation
BitTitan MigrationWiz	Per-license	Mailbox + OneDrive bulk migration; per-license predictability	Complex Teams chat coexistence
Quest On Demand Migration	Subscription	Identity coexistence; Teams chat-history migration; longer windows	Cost on smaller engagements
ShareGate	Annual subscription ($9,995–$17,995/yr)	SharePoint + OneDrive permission preservation; smaller scopes	Mailbox-only scenarios; pure Teams workloads
CodeTwo	Per-mailbox + subscription	Email-focused migrations; signature management add-on	Broad workload coverage; Power Platform

Most projects pair two tools — typically a commercial tool for the bulk workload plus Microsoft-native for the workloads where the commercial tool has gaps. We don't resell any of these; the recommendation is what fits your project, not what pays us best.

Realistic budgets

For a typical M&A integration scenario:

Org size	Tooling cost	Labor cost (delivered)	Total
50 users	$3K–$8K	$25K–$45K	$28K–$53K
200 users	$8K–$20K	$45K–$85K	$53K–$105K
500 users	$20K–$45K	$85K–$150K	$105K–$195K
1,000+ users	$45K+	$150K+	$200K+

The labor side scales with complexity, not just user count. A 200-user environment with 50 SharePoint sites, 20 Power Platform flows, and a custom Teams app costs more than a 500-user environment that's mostly mailboxes and OneDrive.

Common failure modes

Underestimating Teams

Teams chat history migration is the hardest single workload in tenant-to-tenant. Some tools handle it well, some don't, and the user expectation is "everything moved" — losing chat history is visible and painful. Set expectations early about what's migrating and what isn't.

Power Platform surprises

Power Apps and Power Automate connection references break on migration in subtle ways. A flow that worked in the source tenant may not work in the destination because the connection it uses doesn't exist there yet. Inventory every flow and every app, and plan for re-authorization at minimum.

Guest users

The destination tenant's external-collaboration policies may not match the source's. Guest users that worked in the source may not be able to access the same content in the destination. Inventory guests early.

Domain ownership transfer

The custom domain (`@yourcompany.com`) can only be active in one tenant at a time. The cutover requires removing it from source, adding it to destination, validating, and recreating all email aliases. This is a 30-60 minute window of email disruption that has to be coordinated to the minute.

License timing

Destination tenant licensing has to be in place before users can be migrated. Source tenant licensing has to remain in place until users are confirmed migrated. There will be a period of paying for both. Budget for it.

Skipping change management

Users hate identity changes. Their email password is now different. Their UPN may be different. Their devices need to re-auth. Without explicit communication, training materials, and a help-desk surge plan, the migration becomes a politically toxic event. Don't underweight this.

Related reading

• For the M&A version of this playbook with a 60-day deadline and the Power Platform / Teams chat / OneDrive personal-data surprises: Field Notes: M&A 2-Tenant Merge in 60 Days.
• If the source tenant still runs SharePoint Server 2019, the EOL clock is the gating constraint: SharePoint Server 2019 EOL July 2026: three paths.
• Tenant-to-tenant projects often surface unfinished Exchange hybrid decommission or Copilot readiness work that needs to land BEFORE the migration, not during it. Sequence those upstream where possible.
• If your M&A also involves defense contractor work, see GCC High before CMMC Phase 2 — the source-tenant CUI scope can drive a parallel GCC High project.
• Service detail: Tenant-to-Tenant Migration service

Sources and further reading

• Microsoft — cross-tenant mailbox migration
• Microsoft — cross-tenant OneDrive migration
• BitTitan MigrationWiz
• Quest On Demand Migration
• ShareGate

The 30-second version

Tenant-to-tenant migration is the hardest type of M365 work. Realistic budget for a 200-user M&A integration is $50K–$100K all-in. Realistic timeline is 8–16 weeks from kickoff to go-live. Discovery is non-skippable, tooling selection matters, Teams and Power Platform are the surprise-makers, and change management is the part most projects underweight.

To scope yours, the project intake form takes about three minutes. Two-business-day response with scope, tooling recommendation, and a fixed-fee range.

---

Pro IT NW does senior-led tenant-to-tenant Microsoft 365 migrations. Vendor-neutral. Labor-only. We don't resell BitTitan, Quest, or ShareGate licensing — we recommend the right tool for your project and you procure directly.