Identity and email are the parts of an integration that every member of staff notices. People want to find each other in the address book, see each other's calendars and share documents from the first week. That pressure pushes teams to join directories and move mailboxes faster than is safe.
The costs of getting it wrong are concrete. A trust to a directory that has not been checked gives an intruder a route into yours. Mail is lost or bounced during a routing change. A domain left to lapse is registered by someone else. Staff are locked out on a Monday morning. And during a long coexistence you pay for two sets of licences for every user.
When it happens
Plan coexistence before closing, so it can start in the first days or weeks afterwards. Account and mailbox migration follows the end-state decision made in the first 100 days and the connectivity gate from security due diligence. Decommissioning the old directory and email platform comes last, often many months later.
Who is involved
- The identity lead and directory team, who own accounts, groups, trusts and sign-in.
- The email and collaboration platform team, who own mail flow, mailboxes, calendars and sharing.
- The security lead, for the gate, multi-factor authentication and privileged access.
- HR, as the source of truth for joiners, movers and leavers.
- The target's IT team, who know the history of every odd account.
- The service desk, who carry the migration waves.
- Communications, for what staff are told and when.
- Legal counsel, for retention, legal holds and domain ownership.
The steps
1. Set up coexistence first
Coexistence lets people work together while the estates stay separate. It buys time to do the rest properly.
- Contacts synchronised so each side appears in the other's address book
- Free/busy and calendar sharing between the two email platforms
- Guest access for shared documents and workspaces
- Meetings that work across both organisations
- No merged accounts and no directory trusts at this stage
2. Decide between trust, federation and migration
There are several ways to give people access across the two estates, and they carry different risk.
- Directory trust: quick access to resources, but it extends each directory's attack surface to the other. If you need one, make it one-way, limited to named resources and time-boxed, and only after the gate is passed.
- Federation and single sign-on: access to applications without joining the directories. Often the safest interim step.
- Migration into one directory: the cleanest end state, and the most work.
- Keep separate: right when regulation, a planned onward sale or a separate operating model call for it.
3. Clean up accounts before you move them
Do not migrate the mess. Review every account in the target's directory and decide whether it moves, changes or goes.
- Stale accounts with no recent sign-in, measured against a threshold you set
- Members of privileged groups, each with a named person and a reason
- Service accounts: owner, purpose, password age, whether they can sign in interactively
- Shared and generic accounts and mailboxes, each with an owner
- Accounts of former staff, contractors and suppliers
4. Bring multi-factor authentication and the account lifecycle under control
Close multi-factor gaps before migration, not after it. Use phishing-resistant methods for administrators. During coexistence a leaver has an account in both estates, so the leaver process has to reach both.
- Multi-factor authentication for all users, starting with administrators and remote access
- A joiners, movers and leavers process fed from HR, covering both directories
- Leavers disabled in both estates at the same time
- A single lifecycle process once migration is complete
5. Plan email domains, routing and authentication
Keep every domain the target uses, even the ones that look obsolete, and give migrated users addresses on both the old and new domains. Mail routing during coexistence must deliver to whichever platform holds the mailbox at the time.
- Every sending and receiving domain listed, with its registrar and renewal date
- Old domains kept registered and renewing; a lapsed domain can be registered by anyone
- Aliases so each user receives mail at every address they have used
- A mail flow design for coexistence and for each wave
- SPF records for each domain, kept within the DNS lookup limit
- DKIM keys for every platform that sends on the domain's behalf
- DMARC alignment checked before tightening the policy, with reports reviewed
- Third-party senders on old domains, such as billing, marketing and ticketing systems
6. Migrate in waves
Start with a pilot group, usually IT, then move by department or site. Keep people who work together in the same wave.
- Prerequisites for each wave: accounts cleaned, licences assigned, devices ready
- Managers and their delegates in the same wave, with shared mailboxes alongside
- Mobile devices and desktop profiles handled in the runbook
- Archives, retention settings and legal holds carried across
- Forwarding from the old mailbox for a defined period
- Floor support on the day after each wave, and a rollback point
7. Reconcile licences
Coexistence means paying twice for some users. Track it so it ends.
- Licences per user on each platform, by wave
- Contract renewal dates on both sides
- A date to release the old platform's licences
8. Decommission the old estate
Retire the old directory and email platform only after retention duties are met and everything has been moved, exported or deliberately left behind.
- Retention and legal hold requirements confirmed with counsel
- A final export or backup held for the agreed period
- Trusts and synchronisation removed
- Certificates revoked and service accounts deleted
- DNS records for retired services removed, so they cannot be taken over
- Old domains kept, with mail routed and DMARC in place
Common traps
- A two-way trust on day one to a directory that has not passed the gate
- Migrating stale and privileged accounts unchanged
- Letting an old domain lapse
- Breaking SPF by adding includes beyond the lookup limit
- Tightening DMARC before every legitimate sender is aligned
- Forgetting third-party systems that send mail on an old domain
- Splitting managers and their delegates across waves
- Leavers disabled in one directory but not the other
- Decommissioning before retention and legal hold requirements are met
- DNS records left pointing at retired services
What you hand over
- The coexistence design and its status
- The access decision (trust, federation, migration or separate), signed off by security
- The account clean-up record
- Mail routing design, and SPF, DKIM and DMARC status for every domain
- Wave plans, runbooks and results
- A licence reconciliation
- The decommissioning record, including retention arrangements
Where MNA Tools helps
- DeepReview lists the domains and brands the target uses, from public information, including ones nobody put on a list, so no domain is forgotten when you plan routing and renewals. Its leaked-credential findings help you decide where to close multi-factor gaps first.
- HouseGRC records the exceptions, such as a trust kept beyond its end date or a service account that cannot yet be changed, as owned, dated risks.
A general guide to the technology side of a deal, not legal, tax or financial advice. Adapt it to the deal in front of you, and take advice where the stakes call for it.