Mergers and acquisitions do not care about your tenant architecture. The deal closes, legal wants one company in the market, and IT inherits two Office 365 tenants, two Azure AD directories, overlapping SMTP domains, and a date on a slide that said "synergies." Tenant-to-tenant migration is the M&A playbook item that decides whether Monday feels like one firm or two inboxes and a prayer.
We have run mailbox and identity moves for large hybrid programs and smaller cutovers. This post is the pattern that keeps working: treat tenant-to-tenant as identity and DNS first, content second, and never as a pure MigrationWiz exercise.
Scenarios, not one tool
Acquisition into buyer tenant. Source tenant dies or becomes a stub; users, mail, and most collaboration land in the buyer tenant. Most common.
Divestiture out of parent tenant. Slice of users and data must leave cleanly with domain portability and without taking the parent's entire GAL hostage.
Merge of equals. Politics choose the surviving tenant; architecture should still pick one survivor early. "We'll sync both forever" is not a strategy.
Each scenario changes domain move order, UPN strategy, and how long coexistence lasts. The tooling rhymes; the runbooks do not copy-paste.
What actually has to move
- Identities. Users, groups, guest strategy, admin roles. Azure AD Connect topologies if either side is hybrid.
- Exchange Online mailboxes and content. Including shared mailboxes, resource mailboxes, and delegation.
- OneDrive and SharePoint. Often larger and slower than mail; permissions and sharing links break in ways users discover late.
- Teams and related workloads. In 2018 this is still maturing; some teams rebuild rather than migrate. Be honest in the plan.
- Domains. The public brand domain must end on the surviving tenant. That cutover is the emotional midpoint of the project.
- Devices and applications. SSO app gallery assignments, certificate trust, Wi-Fi EAP identities — the day-two pile.
BitTitan MigrationWiz and similar tools move a lot of mailbox and OneDrive content well. They do not replace domain planning, identity mapping, or change management.
Identity mapping before any content job
Build the map: source object to target object, UPN old to UPN new, SMTP primary and aliases, group membership, shared mailbox ownership. Collision resolution (two jsmiths) is a business decision recorded before wave one.
If the buyer is hybrid, decide whether source users become cloud-only in the target or enter via AD Connect from a consolidated forest. Forest consolidation and tenant-to-tenant in the same quarter is how programs melt; sequence them.
Domain cutover sequencing
The scary weekend is usually domain move, not the bulk mailbox copy. Pattern:
- Pre-stage content into the target tenant while source remains authoritative for mail.
- Lower TTL on MX and related records ahead of time.
- Remove domain from source tenant (Exchange and Azure AD dependencies cleared).
- Add and verify domain on target tenant.
- MX, Autodiscover, SPF, DKIM, DMARC updates.
- Delta sync content; cut user outlook profiles / modern auth as designed.
Mail flow during the switch needs an explicit answer for messages in flight and for partners who cached old DNS. Keep the bridge line staffed.
What tools do vs what people do
Tools: mailbox item copy, OneDrive copy, scheduling, some reporting, retries.
People: identity design, domain politics, application re-consent, Teams/SharePoint information architecture, executive communications, helpdesk scripts, "why is my phone not getting mail" at 7 a.m. Monday.
Budget both. A cheap tool license with no senior identity engineer is not a cheap project; it is a deferred outage.
Minimal-downtime framing
Users hear "no downtime." Architects should say planned short disruption window for domain and profile reconfiguration, with bulk content pre-staged so the window is not a multi-day copy. Historical mail available Monday is a design goal; silent incomplete migrations are the failure mode.
SharePoint and OneDrive: the quiet majority of bytes
Mail gets the executive attention. OneDrive and SharePoint often dominate bytes and elapsed time. Sharing links, permissions, and hub sites do not always survive tooling the way humans expect. We:
- Inventory external sharing and guest access before move
- Decide rebuild vs migrate for complex team sites
- Communicate that some sharing links will break and how to re-share
- Stage large OneDrive accounts early; do not leave the CEO's 200 GB drive for the cutover night
Teams workload in late 2018 is still a judgment call per tenant maturity. Document whether you migrate, rebuild, or dual-run chat. Silence here becomes anger later.
Application re-consent and SSO
Every SaaS app federated to the source tenant needs a plan: re-point SAML/OIDC to the surviving tenant, re-assign users, re-test. The list is always longer than Azure AD's enterprise applications blade suggests — shadow IT shows up when the VP of sales cannot open the CPQ tool on Monday. Assign an application owner to each critical app before the weekend.
Communications timeline
- T-14 days: who moves, what changes, what stays
- T-1 day: freeze rules, support numbers, expected symptoms (re-login, phone re-activation)
- T+0: bridge open, status page if you have one
- T+1 to T+7: known issues list updated twice daily
M&A users are already stressed by the business change. IT silence feels like contempt even when engineers are drowning.
Risk register excerpts from real programs
- Domain remove blocked by an enterprise app still using the vanity domain on the source tenant — inventory apps early
- Hybrid mis-merge when both companies run AD Connect to different forests — identity program must lead
- Litigation hold and retention differences between tenants — legal must sign the mapping
- Guest users lost or duplicated — decide guest strategy explicitly
- Power BI and other workloads forgotten until an executive dashboard dies — expand the workload checklist beyond Exchange
Roles on the bridge
- Identity lead (Azure AD / UPN / groups)
- Messaging lead (mail flow / MigrationWiz or native)
- Collaboration lead (SharePoint / OneDrive / Teams decision)
- Network/DNS lead
- Comms / helpdesk lead
- Business sponsor with authority to slip date if safety requires
If one person is all of the above, you do not have a tenant-to-tenant program. You have a hero narrative.
If you're facing this
If the integration management office just assigned you "merge the tenants" with a date and no domain plan, stop and write the identity and DNS runbook first. We run tenant-to-tenant and hybrid M&A moves; bring both tenant admin contacts and the real list of domains that must work on day one.