Merger and Acquisition Email Migration: A Practical Playbook

An M&A email migration is not a normal migration with a corporate logo change. It is a controlled merging of two organisations' identity, mail flow, namespaces, and compliance posture, often under deal-driven deadlines and with limited information until close. The playbook in this guide assumes you are the IT lead at the acquiring side (or the integrating side of a merger of equals) and walks through what to do before close, in the first 30 days after close, during coexistence, and through final consolidation.

Why M&A email migrations are different#

Three things make M&A migrations unlike any other.

First, the legal boundary. Until close, the target company's data is somebody else's. You cannot copy a mailbox, you cannot enumerate a directory, you cannot even confirm a mailbox exists, unless a specific clean-team or transition-services agreement says you can. After close, the data is yours, but the access change happens on a specific day at a specific hour and the planning must accommodate that hard line.

Second, the identity model. The two organisations have separate identity providers, separate UPN structures, separate password policies, and separate MFA postures. Merging identities is a project in its own right and it must complete (at least partially) before mail can be merged cleanly.

Third, the namespace. The acquired company has its own domain, often domains. Decisions about which domain survives, which becomes a redirect, and which gets retired are organisational decisions with months of brand and legal review behind them. Email migration has to fit into that namespace decision, not the other way around.

A normal migration starts with a clean assessment. An M&A migration starts with a non-disclosure agreement, a deal calendar, and a series of legal "what can we touch right now" questions.

The phased model#

The right shape for an M&A email migration is four phases. Each one has its own deliverables and its own constraints.

1. Pre-announcement / due diligence: under NDA, limited access, planning only
2. Announcement to close: design and procurement, no data movement
3. Close to Day 100: identity merge, mail flow integration, pilot migrations
4. Day 100 to consolidation complete: bulk migration, namespace consolidation, post-close cleanup

The first phase may be invisible to most of the IT organisation. The fourth phase often runs for 12 to 24 months on larger deals.

For the broader operational mechanics of moving mail between organisations, pair this playbook with the tenant-to-tenant migration guide.

Phase 1: pre-announcement and due diligence#

The deal team knows. A handful of IT and security leaders know under NDA. The rest of the organisation does not.

What you can do#

• Read whatever discovery documents the deal team has on the target's IT estate
• Estimate the size of the migration from publicly available signals (employee count, domain count, public job ads for IT roles that hint at platform)
• Identify the small number of internal stakeholders who must be informed before close
• Begin licence procurement modelling at the destination tenant
• Start the legal review on data handling — who owns the data at close, where it can live, what compliance regimes apply

What you cannot do#

• Touch the target's mail systems
• Talk to the target's IT staff outside of clean-team interactions
• Provision destination accounts that look identical to the target's
• Communicate with the target's users about the eventual migration

The clean-team exception#

In many deals, a "clean team" is established — a small group with access to both sides under strict legal controls, whose work product is held back until close. If the deal has a clean team, your IT representative on it can review the target's mail environment, ask clarifying questions, and produce a redacted assessment. The output of the clean team becomes your Day 0 starting line.

Phase 2: announcement to close#

The deal is public. The integration planning ramps up but legal separation still applies.

Set up the integration management office#

Email migration is one workstream inside a broader integration. Make sure email integration has a named owner, a clear scope, and a place at the IMO table. Email decisions interact with HR (when do new hires from the target appear in the directory?), legal (when does data residency apply?), and brand (which domain stays?).

Stand up the destination capacity#

If the acquired company has 1,500 mailboxes and you have 8,000, you need licences and tenant capacity for 9,500 before mail starts to move. Procurement lead times for some platforms are measured in weeks, not days. Start early.

Design the identity model#

The single most consequential pre-close decision is the identity model. You have three realistic options:

• Absorb into existing IdP: target users get accounts created in your existing identity provider, with UPN remapping if names collide. Best when the target is significantly smaller and absorbing fast is the goal.
• Federate temporarily: target IdP and source IdP federate. Users keep their original sign-in for now. Best when both organisations are large and absorption is going to take a year or more.
• New tenant for the combined company: rare but appropriate for true mergers of equals. Both organisations migrate to a clean third tenant.

The identity model decides the migration model. If you absorb, you can plan a tenant-to-tenant migration starting at close. If you federate, you are planning for a hybrid period of indeterminate length.

Define the namespace strategy#

Two domains exist: acquirer.com and target.com. After close, the choices are:

• Keep both domains routable; users keep their original primary address; new hires get assigned to one of the domains by policy
• Make acquirer.com primary; add acquirer.com as a secondary SMTP on every target user (so they still receive mail to their old address)
• Migrate everyone to acquirer.com and decommission target.com after a transition period

The third option has the most communications complexity (every external contact of a target user must update their address book) and the cleanest end state. The choice usually depends on brand strategy. For the operational implications of the address change itself, see the domain change email migration guide.

Pre-close legal checks#

Before close, get sign-off on:

• Data residency: where will combined mail live? Does the target have data that cannot leave its current region?
• Retention: does the target operate under retention obligations the acquirer does not? The stricter regime wins.
• Hold register: what mailboxes at the target are on legal hold? They must come across with the hold intact.
• Privacy notices: do user-facing communications about the migration need legal review per jurisdiction?

If you skip these, you will find them post-close and they will block the migration for weeks.

Phase 3: close to Day 100#

Close is a milestone, not a finish line. The first 100 days are when the bulk of the integration shape gets set.

Day 0–7: secure the boundaries#

Within the first week:

• Establish admin access to both source and destination
• Run the formal assessment (now you can — see the pre-migration assessment discipline applied to the target's environment)
• Confirm or revise the size, the user count, and the risk picture against the clean-team estimate
• Snapshot the target's DNS — every MX, SPF, DKIM, DMARC, autodiscover, and TTL — and store it
• Snapshot the target's distribution list and shared mailbox inventory
• Snapshot the target's retention holds

Day 7–30: identity and pilot#

In the second three weeks:

• Provision the identity bridge per your chosen model (absorb, federate, or new tenant)
• Create destination accounts for every target user, with placeholder primary addresses
• Add the target's domain(s) to the destination tenant as accepted domains
• Run a pilot migration of 10–20 friendly users from the target
• Validate the pilot end-to-end including calendar, mobile, and shared mailbox access
• Brief the target's help desk on the integrated escalation path

Day 30–100: bulk migration runway#

If the deal calls for fast integration, this is when the migration waves run. If it calls for measured integration, this is when you stand up the long-running hybrid.

The wave plan looks much like a normal staged migration plan with one modification: each wave should be all-of-a-business-function rather than all-of-a-department. Sales people work with sales people in spreadsheets, sales people on the target side work with sales people on the acquirer side in newly merged spreadsheets — moving them together preserves the working relationships across the migration boundary.

The identity merge in detail#

Identity merge is the single hardest piece of M&A email migration. It deserves its own treatment.

Name collisions#

Both companies have a Sarah Johnson. The target's sjohnson@target.com and the acquirer's sjohnson@acquirer.com both exist and both make sense to their respective Sarahs. When you bring them into the same directory, you need a rule.

Options:

• Append the original tenant suffix to one of them (sjohnson.t@acquirer.com)
• Use full names where collisions occur
• Allow target users to keep their original addresses indefinitely
• Force everyone to a firstname.lastname@ format and rebuild from scratch (most disruptive)

The right answer depends on how user-facing the addresses are. For a 12,000-person organisation where 200 collisions occur, individually managing each collision case is acceptable. For a 50,000-person organisation with 4,000 collisions, you need a deterministic rule.

MFA reconciliation#

The acquirer enforces TOTP-based MFA. The target uses SMS-based MFA. After identity merge, target users need to enrol in the acquirer's MFA system. Do this before mail migration, not after, because mail migration creates many new sign-in events that will trip MFA enrolment prompts mid-migration.

Conditional access alignment#

If the acquirer blocks legacy authentication and the target permits it, you will break every basic-auth IMAP client in the target's estate the moment the merged conditional access policy applies. Audit the target's auth landscape before applying the merged policy.

Service accounts#

The target has service accounts that send mail. They will need to be re-created in the merged identity model, with the appropriate OAuth grants for the destination platform. Inventory them as part of the Day 7 assessment.

Namespace consolidation#

Once mail is flowing in the combined environment, namespace consolidation is the long tail.

The three-stage pattern#

1. Both domains live, both as primary: target users have user@target.com; acquirer users have user@acquirer.com; both work
2. Acquirer primary, target as alias: target users get user@acquirer.com added as a primary SMTP; user@target.com continues to deliver but new outbound goes from the acquirer address
3. Target domain retired: external senders to user@target.com get an auto-reply with the new address; eventually the domain is decommissioned

Stage 3 is when most organisations get stuck. There is always one supplier, one regulator, one customer who still has the old address in their system and who you cannot easily reach. Plan for the long tail: stage 3 typically runs 12+ months.

DNS during consolidation#

During stage 1, both domains have their own MX records pointing at the merged mail destination. During stage 2, both still have their own MX. During stage 3, the target's MX records are kept active even though primary delivery has shifted — only the inbound flow changes when you finally retire the domain.

Keep DNS TTLs at normal long values during steady-state but plan to reduce them temporarily before any stage transition.

Regulatory data handling#

M&A migrations attract more regulatory attention than ordinary migrations. The triggers vary by jurisdiction but the patterns are similar.

Personal data and GDPR-equivalent regimes#

In Europe and many other jurisdictions, the merger itself is a processing event that requires legal grounding. Email migration that moves personal data across borders or between controllers needs documentation. Work with your legal team on the Data Processing Impact Assessment before mail movement starts.

Sector-specific regulation#

If either company operates in a regulated sector (finance, healthcare, defence, energy), additional rules apply:

• Mailboxes subject to journaling must continue to journal through the migration
• Retention holds must be preserved bit-for-bit
• Data residency requirements may force a phased move
• Some mail may not be moveable at all and must remain on the source system as a legal archive

The email migration compliance guide covers the cross-cutting rules in detail.

Coexistence operations#

During the 90–180 day coexistence period, both systems are production. The operational rules during coexistence:

• One IT organisation, one help desk, one ticket queue — even if the two underlying mail systems still differ
• A single weekly status report on integration progress
• A merged change-control board for any change touching the integrated mail flow
• A single major-incident process across both systems
• Common SLAs for both populations

Two help desks running side by side will diverge in their information and their responses within a month. Merge them on Day 1 if at all possible.

Pilot before bulk#

Always pilot a small group from the target before bulk migration. The pilot will surface:

• Identity issues that the assessment did not predict
• Conditional access edge cases
• Mobile MDM gaps (target devices are managed by the target's MDM; merging MDMs is its own project)
• Calendar federation oddities (especially with external attendees of pre-merger meetings)

A 20-user pilot for 14 days catches more issues than a perfect plan on paper.

Post-close cleanup#

After the last mailbox moves, the integration is not done.

Decommission the source#

When you can finally retire the target's source mail platform:

• Confirm all retention obligations are now satisfied by the destination's archive
• Export any data the destination cannot ingest natively to a controlled archive store
• Capture a final inventory snapshot for the deal records
• Shut down the source environment in a documented, dated sequence
• Cancel the source platform's licences

Source decommission is often delayed by one undiscovered dependency: a billing system that mails invoices from a target-side address, a regulator that has the target's old SMTP host in a whitelist, a partner whose security policy hard-codes the target's outbound IP. Plan a 30-day quiet period between "last user moved" and "decommissioned" to flush these out.

Update the address books of the world#

For 6–12 months after consolidation, the address books of external senders will still contain old target addresses. The target domain must keep accepting mail in some form during that period. You have three options:

• Forward user@target.com to user@acquirer.com indefinitely
• Auto-reply with the new address and drop the message
• Bounce after a defined period and let senders self-correct

Most organisations choose forwarding for the first year and then transition to auto-reply.

Final compliance close-out#

Document the migration for the deal records:

• Final mailbox count moved, by domain
• Holds preserved, with verification
• Retention policy delta and how it was reconciled
• Any data not moved, with the legal basis
• Sign-off from compliance and legal

This document becomes part of the deal's permanent record. Future auditors will read it.

What the migration tool needs to do#

For M&A migrations, your tool needs capabilities that ordinary migrations may not demand.

• IMAP-native operation against any target mail system, because you will not always know what the target runs until close
• Local execution so the migration is not bottlenecked by the destination vendor's hosted infrastructure
• Resume on failure across multi-day runs
• Per-mailbox audit logs you can hand to a compliance reviewer
• Support for shared mailboxes, distribution lists, and resource calendars in addition to user mailboxes
• The ability to throttle conservatively against destinations whose limits you have not yet learned

Mailbox Taxi is built for this profile: IMAP-native, runs locally on Windows, Mac, or Linux, supports 10+ providers including provider-specific quirks for Gmail, Outlook, Yahoo, iCloud, Zoho, AOL, ProtonMail Bridge, Fastmail, GMX, and Yandex, and produces per-mailbox reports suitable for audit.

The cross-link to divestitures#

The mirror image of M&A is divestiture: a business unit splits off and must take its mail with it. Many of the same patterns apply in reverse — namespace separation rather than consolidation, identity split rather than merge, separate retention regimes rather than merged ones. If you are running an M&A integration and a divestiture is on the horizon (or vice versa), pair this playbook with the divestiture email migration guide.

For the full operational sequence that any of these complex migrations sits within, the complete email migration guide is the parent document.