SharePoint Tenant-to-Tenant Migration for M&A: The Enterprise Playbook

SharePoint Tenant-to-Tenant Migration: The M&A Playbook

Tenant-to-tenant migrations are the most complex SharePoint projects that exist. You are not just moving documents — you are merging two identity systems, two permission models, two information architectures, and two organizational cultures. Everything is happening under a deal deadline that the business team negotiated without consulting IT. And if you lose data or break access during the transition, the deal integration stalls.

I have led tenant consolidations for organizations ranging from 2,000 to 25,000 users. Our largest was a 25,000-user, 4TB consolidation completed within a 90-day acquisition deadline for a retail conglomerate. Here is the playbook.

---

Why Tenant-to-Tenant Is Harder Than Any Other Migration

A standard migration (on-prem to Online) moves content from one system to another. A tenant-to-tenant migration requires solving problems that do not exist in any other migration type:

Identity mapping. Every user in the source tenant has a different UPN (User Principal Name) than they will have in the target tenant. [email protected] becomes [email protected]. Every permission, every document owner, every workflow creator, every People column value must be remapped. Miss one, and a user loses access to their own documents.

Duplicate content resolution. Both companies have a "Finance" SharePoint site. Both have an "HR Policies" document library. Both have a "Company Handbook." You cannot merge blindly — you need a content deduplication and restructuring strategy.

Coexistence period. Unlike a clean cutover, M&A migrations often require 30-90 days where both tenants are operational simultaneously. Users need to access content in both tenants during the transition. This requires cross-tenant sharing, guest access, or a hybrid configuration.

Legal and compliance overlay. M&A transactions involve confidentiality requirements. During the pre-close period, only certain employees can access the acquired company's content. Information barriers, sensitivity labels, and access controls must prevent premature content mingling.

---

The 5-Phase M&A Migration Framework

Phase 1: Due Diligence IT Assessment (Pre-Close, 2-4 Weeks)

Before the deal closes, the IT team must assess:

• Source tenant inventory: Number of users, data volume, site collections, custom solutions, third-party integrations, compliance configurations.
• Identity overlap: Do any users exist in both tenants? What email domains will be retained vs. retired?
• Licensing gap: Does the target tenant have sufficient M365 licenses for the acquired users? What license tier are they on?
• Compliance requirements: Are there data residency restrictions? Information barriers needed? Retention hold requirements for deal documentation?

This assessment drives the migration timeline and budget that IT provides to the deal team.

Phase 2: Identity and Architecture Planning (Close + Weeks 1-4)

Once the deal closes and IT has legal access to both environments:

• Design the identity mapping: Source UPN to target UPN for every user. Decide: new email domain, alias retention, distribution list merging.
• Design the target information architecture: Where does the acquired company's content go in the parent's SharePoint environment? Options: separate hub site (maintains identity), merged into existing hubs (full integration), or hybrid (some content merges, some stays separate).
• Plan the coexistence configuration: Cross-tenant access during migration, guest accounts, Azure B2B, or third-party coexistence tools.
• Configure the migration tooling: AvePoint FLY, ShareGate, or BitTitan with cross-tenant authentication.

Phase 3: Pre-Migration Setup (Weeks 4-6)

• Create target user accounts in the parent tenant (synced from acquired company's Entra ID or provisioned manually).
• Provision target SharePoint sites per the architecture plan.
• Deploy sensitivity labels and DLP policies to the target sites before content arrives.
• Configure cross-tenant sharing for the coexistence period.
• Test migration tooling with a small sample (10 users, 1 site) to validate identity mapping, permission translation, and metadata preservation.

Phase 4: Phased Content Migration (Weeks 6-16)

Execute the migration in waves:

Wave 1: Shared services (HR, Legal, Finance) — These departments typically need unified content first for deal integration activities. Migrate shared policies, org charts, benefits information.

Wave 2: Department by department — Migrate each department's SharePoint sites, document libraries, and Teams in sequence. Each wave follows the pattern: bulk transfer (80% of content), delta sync (ongoing changes), validation (content integrity + permissions), cutover (redirect users to target), and hypercare (1 week per wave).

Wave 3: Executive and sensitive content — CEO staff, board documents, M&A deal room content. Migrate last with the tightest access controls.

Wave 4: Archive and cleanup — Migrate historical content, apply retention labels, decommission unnecessary sites.

Phase 5: Cutover and Decommission (Weeks 16-20)

• Final delta sync for all content.
• DNS cutover: Redirect acquired company's email domain to the parent tenant.
• Decommission source tenant: Set source tenant to read-only for 30 days, then terminate the subscription.
• Post-migration audit: Verify all content, permissions, and integrations are functional.
• User communication: Provide migration guides, new login instructions, and support resources.

---

Identity Mapping: The Make-or-Break Factor

The most common failure point in tenant-to-tenant migrations is identity mapping. Get this wrong and users cannot access their own documents.

What must be mapped:

• User Principal Names (UPN) — source to target
• Security groups — source groups to target groups (or merged groups)
• Distribution lists — merge, rename, or recreate
• Shared mailboxes — if used for SharePoint alerts or workflows
• Service accounts — if used for automated processes
• External guests — re-invite in target tenant if needed

The mapping file is a CSV that your migration tool uses to translate every permission. A 5,000-user organization will have a mapping file with 5,000+ user entries, 200+ group entries, and 50+ special account entries. Validate this file obsessively before production migration.

Common identity mapping mistakes:

• Forgetting to map groups (only mapping individual users, leaving group-based permissions broken)
• Not handling users who exist in both tenants (duplicate accounts need to be merged, not duplicated)
• Ignoring People columns in SharePoint lists (these store user identities that must be remapped)
• Missing service accounts used by Power Automate flows or third-party tools

---

Cost and Timeline Estimates

| Acquisition Size | Users | Data Volume | Estimated Cost | Timeline |

|-----------------|-------|-------------|---------------|----------|

| Small | Under 1,000 | Under 1TB | $50,000-$100,000 | 8-12 weeks |

| Medium | 1,000-5,000 | 1TB-10TB | $100,000-$250,000 | 12-16 weeks |

| Large | 5,000-15,000 | 10TB-30TB | $250,000-$500,000 | 16-24 weeks |

| Enterprise | 15,000+ | 30TB+ | $500,000-$1,000,000 | 24-36 weeks |

These include assessment, planning, tooling, execution, validation, training, and 30-day post-migration support. The business team will ask if this can be done faster and cheaper. The answer is: faster, or cheaper, or correct — pick two.

---

Coexistence Strategies During Migration

| Strategy | Complexity | User Experience | Best For |

|----------|-----------|----------------|----------|

| Cross-tenant guest access | Low | Moderate (separate logins) | Short coexistence (under 30 days) |

| Azure B2B collaboration | Medium | Good (SSO possible) | Medium coexistence (30-90 days) |

| Third-party coexistence tools | High | Best (seamless) | Long coexistence (90+ days) |

| Big-bang cutover | Low | Disruptive | Small acquisitions (under 500 users) |

For most M&A migrations, Azure B2B with conditional access policies provides the best balance of security, user experience, and implementation complexity.

---

Frequently Asked Questions

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

3-9 months depending on the number of users, data volume, customization complexity, and compliance requirements. Our fastest was a 2,000-user consolidation in 8 weeks. Our most complex was a 25,000-user consolidation across 4 acquired companies in 6 months.

Can I migrate Teams alongside SharePoint?

Yes — and you should. Every Teams team has a SharePoint site. When you migrate the SharePoint content, you should simultaneously migrate the Teams configuration (channels, tabs, conversations if needed). Migration tools like ShareGate and AvePoint handle Teams migration alongside SharePoint.

What happens to OneDrive content during a tenant migration?

OneDrive content must be migrated separately from SharePoint sites. Each user's OneDrive is essentially a personal SharePoint site collection. Map each source OneDrive to the target user's OneDrive using the identity mapping file. Data volume from OneDrive often exceeds SharePoint — budget accordingly.

Do we need to migrate Exchange/email at the same time?

Not necessarily, but it is strongly recommended. Users expect email, calendar, and files to move together. A phased approach is possible (move email first, then SharePoint/OneDrive, or vice versa), but the coexistence complexity increases with each phase. The cleanest approach is a coordinated cutover per department.

What about Power Automate flows that reference the old tenant?

Power Automate flows that reference SharePoint sites in the source tenant will break after migration. During Phase 2, inventory all Power Automate flows, identify which ones reference SharePoint content, and plan to recreate or update them in the target tenant. For complex flows, export the flow definition, update connection references, and import into the target.

Can we keep the acquired company's domain name?

Yes. After migration, add the acquired company's email domain as an accepted domain in the target tenant. Users can retain their original email addresses as aliases or primary addresses. This is a DNS change, not a SharePoint configuration — but it affects user identity and should be coordinated with the SharePoint migration.

How do we handle confidential pre-close content?

Use information barriers and sensitivity labels to restrict access to M&A deal content. Only users explicitly authorized by the deal team should have access. After close, these restrictions can be relaxed per the integration plan. Document all access decisions for legal/compliance records.