The M&A Microsoft 365 Tenant-to-Tenant Migration Checklist

Why M&A tenant separation is different

A Microsoft 365 tenant-to-tenant migration in an M&A context isn't just a mailbox move. There's a Transition Service Agreement (TSA) with a hard end date, a target entity that may not exist yet, identity that has to be carved out cleanly, and a regulator or auditor watching the cutover. Standard "lift and shift" playbooks miss the constraints that actually drive the project: a fixed deadline, contested data ownership, and end-users who need working email, identity, and access on Day 1.

This checklist is organized around the three phases that matter for M&A — pre-migration assessment, identity cutover, and post-migration validation — with the coexistence work that sits between them.

Phase 1 — Pre-migration assessment

The goal of the assessment phase is to make the project bid-able and bound — a defensible scope, timeline, and risk register before a single mailbox moves.

Deal & scope inputs

• TSA terms — end date, extension options, penalty clauses, what the seller is and isn't responsible for, and what data the seller will retain.
• In-scope users, mailboxes, and shared mailboxes — per legal entity, with a flag for executives, regulated roles, and shared accounts.
• In-scope SharePoint sites, OneDrive accounts, and Teams — including private channels, external sharing links, and sensitivity labels.
• In-scope Entra ID (Azure AD) objects — users, groups, service principals, conditional access, app registrations, B2B guests.
• Bound systems — anything SSO-federated to the source tenant (HR, ERP, expense, ITSM, badge, VPN, code repos).

Discovery you must run, not assume

• Mailbox sizes, item counts, archive mailboxes, litigation hold, retention policies.
• OneDrive size per user and a SharePoint site inventory with permissions depth.
• Teams inventory with owners, private channels, and any apps publishing data into channels.
• Entra ID app inventory — every app using the source tenant for SSO, with owner and renewal contact.
• MDM/Intune posture — enrolled devices, compliance policies, autopilot profiles, app deployments.
• DNS records the source tenant currently owns (MX, SPF, DKIM, DMARC, autodiscover, MS=verification).

Decisions you need before cutover

• Target tenant — stand up a new tenant, consolidate into an acquirer's tenant, or split into both.
• Domain strategy — keep the existing domain, move to a new one, or run dual-domain during coexistence.
• UPN & SMTP strategy — new UPNs, retained vanity addresses, and how external senders will be redirected.
• Co-existence window — free/busy, mail flow, and directory sync between source and target while the cutover runs.
• Data ownership — what leaves with the carved-out entity, what stays with the seller, and what gets a forensic copy.

Phase 2 — Identity cutover

Identity is the longest pole. Mail and files can move under coexistence, but until identity is cut over cleanly nothing else is durable. Plan identity first, and treat the rest of the workstreams as downstream of it.

Stand up the target identity plane

• Provision the new Entra ID tenant (or carve out an OU in the acquirer's tenant) with naming, region, and licensing decided.
• Configure custom domains, DNS verification records, and a temporary onmicrosoft.com namespace for fallback.
• Re-create baseline conditional access, MFA, and identity protection policies — do not assume the source policies migrate.
• Build the privileged access model (PIM, break-glass accounts, named admin roles) before any object is moved.

Move users, groups, and devices

• Source-of-truth decision: HR system, AD, or Entra ID — pick one for the target and write the sync rules to it.
• Stage user accounts in the target with matching UPNs, immutableId/SourceAnchor, and license assignments.
• Pre-create groups, dynamic group rules, and distribution lists; reconcile nested membership.
• Plan device re-enrollment (Intune migration or Autopilot re-provisioning) — most user pain on Day 1 lives here.
• Re-issue MFA enrollment guidance and re-register authenticator apps in the new tenant.

Federated and connected apps

• List every SaaS app federated to the source tenant; for each, decide re-federate, dual-federate, or app-password bridge.
• Re-create app registrations and enterprise apps in the target tenant with new client IDs and secrets.
• Rotate any service-principal credentials that will outlive the source tenant.
• Coordinate cutover windows with each app owner — do not flip all federations on the same night.

Phase 3 — Mail, files, Teams & coexistence

The data workstreams run in parallel under a coexistence layer so users keep working while content moves. Sequence them so the most disruptive cutovers happen after identity is stable.

Mail flow & mailboxes

• Stand up coexistence: shared address space, free/busy across tenants, and centralized mail flow during cutover.
• Migrate mailboxes in waves (pilot, IT, executives, then bulk) using a tool that supports incremental delta syncs.
• Move archive mailboxes, journaling, and mailboxes on litigation hold with their hold state intact.
• Cut MX records only after the final delta sync and after the target tenant proves outbound mail flow with SPF/DKIM/DMARC aligned.

OneDrive, SharePoint & Teams

• Migrate OneDrive per user with version history and sharing links preserved where the tool supports it.
• Migrate SharePoint sites with permissions, navigation, and sensitivity labels mapped to the target tenant's label taxonomy.
• Migrate Teams with channels, files, tabs, and private channels; re-add bots and apps in the target tenant.
• Communicate the change in sharing links — old URLs break, and external collaborators need new invites.

Endpoint & user experience

• Stage Outlook re-profile, OneDrive re-sign-in, and Teams re-sign-in instructions for each user wave.
• Pre-stage device compliance in Intune so devices don't fall out of compliance the moment users sign in to the new tenant.
• Run a user-facing support channel during each cutover wave with a clear "what's normal vs. what to report" guide.

Phase 4 — Post-migration validation & TSA exit

The work isn't done at cutover — it's done when you can prove the new tenant is operating on its own, the source tenant has been decommissioned to the level the TSA requires, and the auditors have a clean record.

Validation checklist

• Mail flow: inbound, outbound, internal, and external — with SPF/DKIM/DMARC aligned and no source-tenant relays in the path.
• Mailbox completeness: item counts and folder counts reconciled per mailbox, with delta-sync residuals captured.
• OneDrive and SharePoint: file counts, permissions spot-checks, sharing-link audit, and label inheritance.
• Teams: membership, ownership, channel content, and bot/app behavior.
• Identity: every user can sign in, MFA works, conditional access enforces, and PIM elevations are auditable.
• Federated apps: every SSO target authenticates against the new tenant, with no fallback path to the source.
• Endpoint compliance: Intune posture rebuilt, BitLocker recovery keys re-escrowed, autopilot profiles working.

Decommission & TSA exit

• Confirm DNS records the source tenant owned are released or repointed; remove MS=verification records.
• Disable, then delete, the source tenant's user objects per the data-retention agreement.
• Retrieve and store the legal-hold and eDiscovery exports the TSA requires you to keep.
• Sign off the TSA exit with the seller's IT in writing — date, scope, residual obligations.
• Hand the new tenant to BAU operations with runbooks, on-call rotations, and a 30/60/90-day stabilization plan.

Suggested timeline against a TSA

For a typical 6–12 month TSA on a mid-market carve-out, a defensible plan looks like:

1. TSA −180 to −150 days — assessment, scoping, target-tenant design, tooling selection.
2. TSA −150 to −90 days — stand up target tenant, identity plane, baseline policies, pilot wave.
3. TSA −90 to −30 days — bulk mail/files/Teams migration under coexistence, federated-app cutovers.
4. TSA −30 to −7 days — final delta syncs, MX cutover, identity cutover, validation.
5. TSA −7 to 0 days — hypercare, decommission, TSA exit sign-off, hand to BAU.

Compress the window and the risk shifts to identity and federated apps — the two workstreams least forgiving of a rushed plan.