Field Notes: M&A 2-Tenant Merge in 60 Days

The call came on a Tuesday afternoon. "We just closed. We need their tenant merged into ours by [date]." Sixty days. Two Microsoft 365 tenants. One identity model. No room to slip — financial reporting, expense systems, and shared AP/AR workflows all depended on consolidated identity by the deadline. The acquirer was a roughly $8B parent. The subsidiary was a 200-employee specialty firm whose tenant had been running independently for nine years.

Sixty days later, every user was on the parent tenant, every OneDrive had landed, every SharePoint site had rehomed, and the integration tests passed two days post-cutover. This is the anonymized version of how that project actually ran — what was scoped, what surprised us, and what we'd do differently if we ran it again next quarter. It's the M&A companion to our Tenant-to-Tenant M365 Migration Playbook, with the parts that only show up when the deadline is a legal close date.

The shape of the engagement

Anonymized but representative of mid-market M&A integration we see regularly:

• Parent — ~$8B revenue, multi-tenant Microsoft 365 environment with strict integration playbook honed over a dozen prior acquisitions
• Subsidiary — 200 employees, single-tenant M365 E3 environment, ~9 years of accumulated content
• Deadline — legal close + 60 days, driven by financial-reporting consolidation requirements
• Scope — 200 mailboxes, 200 OneDrive accounts (~12 TB), 8 SharePoint sites, 14 Teams, 47 Power Apps, 12 Power Automate flows, ~180 Entra guest users
• Success criteria — every user authenticated against the parent tenant; every business-critical app reachable; financial-system integrations green; documented data-loss tradeoffs accepted by legal in advance

What was scoped (the textbook plan)

On paper, the project looked like a standard tenant-to-tenant migration on an aggressive timeline. The phasing was familiar:

Tooling decisions: Quest On Demand Migration as primary (mailbox + OneDrive + SharePoint + Teams), Microsoft-native cross-tenant features for the identity moves, ShareGate for two SharePoint sites with permission inheritance complexity, and PowerShell for the Power Platform export/import work that no commercial tool handles end-to-end. Vendor-neutral framing: those are the tools that fit; we don't resell any of them.

What surprised us (the parts not in the textbook)

Tenant-to-tenant migration documentation is largely written for greenfield M&A — clean source environments with documented application portfolios. Real engagements have texture. Four surprises drove most of the actual work.

1. Power Platform — 47 Power Apps and 12 Power Automate flows

The diligence handover from the deal team listed "minor Power Platform usage" in the subsidiary tenant. Discovery found 47 Power Apps and 12 Power Automate flows, most of them undocumented and a handful operationally critical. Examples from the actual catalog:

• An expense-approval Power App used by every department head — written by a former IT manager who left in 2022
• A Power Automate flow that synced HR onboarding data from a SharePoint list into an external HRIS via a custom connector
• A Power App used on the production floor for shift-handoff notes — the floor supervisors ran it on shared tablets
• Eleven "small" approval flows that nobody on the IT side knew existed, surfaced only by querying the Power Platform admin center for active flows

Power Platform doesn't migrate tenant-to-tenant the way mailboxes do. Each app and flow had to be exported as a solution package, re-imported into the parent tenant, reconnected to its data sources (often with new connection references because the source connections used subsidiary-tenant service accounts), retested, and re-published. Connection rebuild was the longest part — every connector that pointed at a SharePoint list, a Dataverse table, or an external API needed a parent-tenant credential and a permission review against the parent's data-governance policy.

The shift this caused: Power Platform turned into its own workstream rather than a checklist item. We moved a senior engineer to it in week 2 and kept them on it through cutover. Without that, the timeline would have slipped two to three weeks on Power Platform alone.

2. Shared external apps — guest access to the subsidiary tenant

The subsidiary's vendors — a payroll provider, two industry-specific SaaS apps, a benefits administrator, and a compliance-tracking platform — had been granted access to the subsidiary tenant directly via Entra guest accounts. Some had been granted SharePoint site permissions; some had been added to specific Teams; one had been granted delegated Graph API permissions for an integration we didn't find until a vendor support ticket surfaced it.

None of these access grants survived the tenant move. Each vendor had to be re-invited as a guest in the parent tenant, granted the equivalent permissions on the destination resources, and validated end-to-end with the business owner of that vendor relationship. For one of them — the compliance-tracking platform — the vendor had to update their internal SSO configuration to point at the parent tenant's identity provider, which required a one-week change window on their side that we hadn't budgeted.

The shift this caused: we built a guest-access reconciliation tracker in week 2 — every vendor, every grant, every business owner, every re-invitation status — and ran a weekly review on it through cutover. Without the tracker, three or four vendor relationships would have silently broken at cutover and surfaced as operational fires the following Monday.

3. Teams chat history — Microsoft's tenant-to-tenant migration is messy

Microsoft's cross-tenant Teams migration handles channel messages and team membership reasonably well. It does not handle 1:1 and group chat history cleanly. Some 1:1 chats migrate intact; some lose messages; some lose attachments; some don't migrate at all. The tooling vendors (Quest, BitTitan, ShareGate) each have their own Teams chat migration paths, and each has its own documented limitations.

For an M&A merger, this is a real issue. Users will complain about lost chat history. Legal may have eDiscovery obligations against the source tenant's chat content. The honest answer is that perfect chat-history fidelity across a tenant-to-tenant move is not currently achievable with off-the-shelf tooling at mid-market budget.

The shift this caused: we flagged the data-loss tradeoff in week 1, brought in legal during week 2, and got pre-approval to (a) accept partial chat-history migration with documented gaps, (b) maintain a read-only archive of the source tenant for 13 months post-cutover specifically to satisfy any eDiscovery request, and (c) notify all subsidiary users in advance that 1:1 chat history might be incomplete after migration. With that pre-approval in writing, the chat-history work stopped being a blocker. Without it, we'd have spent two weeks chasing fidelity we couldn't achieve.

4. OneDrive personal data — 200 OneDrives, ~12 TB, mixed quality

Two hundred OneDrive accounts. Roughly 12 TB of accumulated content. The quality range was wide: some users had a few work documents and a clean folder structure; others had nine years of personal photos, family videos, downloaded software, and tax returns alongside their work files. Subsidiary's prior IT leadership had treated OneDrive as "your personal cloud, do whatever," and users had taken them at their word.

The parent's data-governance policy was tighter — corporate OneDrive was for corporate content. Migrating 12 TB indiscriminately would have imported a lot of personal data into the parent tenant with no clear ownership and a compliance question attached. Migrating only "obvious work content" required user judgment that the migration tooling could not make automatically.

The shift this caused: we ran a parallel user-comms track — a clear, written notice to every subsidiary user three weeks before their migration window: "Here's what's about to happen. Here's the parent company's policy on personal content in OneDrive. You have two weeks to decide what stays and what goes. Here's a guide to backing up personal content to your own external storage. Here's the helpdesk path if you have questions." The comms track was more important than the migration tooling. Users who got the message cleaned up; users who didn't, didn't — and that's a known acceptable outcome rather than a surprise audit finding six months later.

What we'd do differently

Three changes we'd make on the next M&A engagement of this shape:

Start the Power Platform inventory in week 0

Not week 1 — week 0. The minute the deal is signed and we have read access to the source tenant, the first query we run is a Power Platform admin center inventory. That single query finds the apps and flows that the diligence brief misses. Every M&A integration we've delivered has had at least an order of magnitude more Power Platform usage than the deal team described. Expect it. Inventory it first.

Run the user-comms track before migration kicks off

OneDrive cleanup, OneNote consolidation, "what's about to happen to your account" — all of this lands better three weeks before user migration, not three days before. On this engagement, we ran the comms track in parallel with discovery and the user response was measured. On a prior engagement where we ran it three days ahead, the helpdesk was overwhelmed for the first week of cutover. Earlier comms is cheaper than late helpdesk surge.

Get legal pre-approval on Teams chat-history fidelity before scoping

The default scoping assumption is "preserve everything." For Teams chat history across a tenant move, that's not a deliverable. Surface the tradeoff in scoping — before the project plan is locked — and get the accepted-data-loss decision in writing. The two engagements where we did this finished on time. The one where we didn't lost a week chasing fidelity that the tooling could not deliver.

The math, in one table

Calendar discipline

1. Day 0 — legal close. Read access granted to source tenant.
2. Day 7 — discovery complete. Power Platform inventory in hand. User-comms track launched.
3. Day 14 — design locked. Legal pre-approvals in writing. Pilot users identified.
4. Day 28 — pilot complete (15 users, all workload classes). Runbook updated.
5. Day 35 / 42 / 49 — cutover waves 1, 2, 3 (~65 users each).
6. Day 56 — hypercare complete, integration tests green, source tenant in read-only state.
7. Day 60 — formal acceptance. Financial-reporting consolidation cutover.

Common mistakes we see in M&A integration scoping

Trusting the diligence brief on Power Platform footprint

Diligence briefs are written by deal teams, not platform engineers. "Minor Power Platform usage" almost always means "we didn't look." Run the admin-center query yourself in week 0. The number you find will not match the number you were told.

Assuming Teams chat history will migrate cleanly

It won't, fully. Get the tradeoff approved by legal before the scoping conversation closes. The data-loss decision is real — surface it early and document it.

Treating user comms as a Day-T-minus-3 task

The user-comms track needs three weeks of runway, not three days. Especially for OneDrive cleanup, where users need time to make decisions about personal content. Earlier comms is cheaper than late helpdesk surge.

Skipping the source-tenant archive plan

eDiscovery, audit, and the occasional "we lost something, can you check" request will land for at least a year post-cutover. Plan for read-only retention of the source tenant for a defined period before decom. Bake the cost into the scope; don't discover it three months later when finance asks why the source-tenant invoice is still coming.

Related reading

• The cross-cutting playbook this engagement extends: Tenant-to-Tenant M365 Migration Playbook.
• If the M&A integration also surfaces an AD modernization conversation: AD Tier-0 in 90 Days: Mid-Market Edition.
• If the source tenant runs SharePoint Server 2019 in addition to SharePoint Online: SharePoint Server 2019 EOL July 2026: three paths.
• If the merged entity is preparing for Copilot rollout: Copilot readiness: the 12,000-permission problem.
• Service detail: Microsoft 365 Migration.

Sources and further reading

• Microsoft Learn — cross-tenant mailbox migration
• Microsoft Learn — cross-tenant OneDrive migration
• Microsoft Learn — moving Power Platform environments across tenants
• Microsoft Learn — cross-tenant Teams migration

The 30-second version

A 200-employee subsidiary of an $8B parent. Two M365 tenants, one identity model, 60 days from legal close. The plan was textbook tenant-to-tenant; the surprises were Power Platform (47 apps, 12 flows — most undocumented), shared external apps (~180 guest grants to reconcile), Teams chat-history fidelity (legal pre-approval needed), and OneDrive personal data (~12 TB, mixed quality, user-judgment required). Completed on schedule, integration tests green at Day 62. The fixes for next time: start Power Platform inventory in week 0, run user comms three weeks ahead of migration, get legal sign-off on Teams chat fidelity before scoping closes.

If you have an M&A integration on the calendar and would like a senior engineer to scope it for your environment, the project intake form takes about three minutes. Two-business-day response with scope and a fixed-fee range.

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