How to migrate mailboxes from Office 365 to… Office 365?Alex Fields
Mergers and acquisitions are probably the most common source of IT headaches in the world. Whenever you have to deal with the complexities of merging two disparate information systems, you know you’re going to run into a number of obstacles. And when both organizations are already on Office 365, in separate tenancies… it’s either very good news or very bad news.
If the goals of the merger do not include sharing a GAL between these entities, or bringing both sets of users under the same primary domain name suffix, then life is good. You could just leave everything where it’s at.
But, if one or both of the above-mentioned criteria needs to be met, I’m afraid the migration path in front of you is a bit gnarly. Microsoft does not provide any native migration tools for accomplishing this, but they do publish this article, which explicitly recommends using a third party tool to accomplish the data move. But there are “poor-man’s” methods for getting this data over as well–more on that soon.
The other (perhaps more alarming) part of this process is that we are recommended to temporarily point the MX records at a bogus (non-existent) location–which will cause mail delivery to enter retry state, and/or possibly generate NDR/bounce-backs. Alternatively, we may use a third-party mail queuing service (which avoids NDR’s). The reason you have to do this is because you cannot associate a domain name with two tenancies simultaneously–it’s just not possible–if you try, it will fail.
Therefore, to accomplish the migration, you will need to:
- Stop mail/redirect MX
- Remove the association of the domain name completely from the source tenant
- Re-associate it with the destination tenant
- THEN migrate
- THEN re-establish the mailflow
Unlike most other migration scenarios, downtime here is unavoidable. Reason being: you can’t deliver mail into the old tenant as you begin the process of removing the vanity domain. And you also can’t redirect the MX records straight-away toward the destination tenant, since the domain name hasn’t been associated there yet, and can’t be–thus mail needs a different place to go in the meantime. Obviously, the best option would be a third party SPAM or queuing service to avoid the possibilities of NDR’s.
Summary of the Migration Path:
- Setup a third-party SPAM filter w/ mail queuing in front of the source tenant (which will be migrated)–switch MX records to deliver mail here temporarily (should still be configured to pass mail through to Office 365)
- If you’re not willing to spend money on a third party tool, I recommend having users run a mailbox clean-up / archive procedure to remove items older than say 6 months or 1 year to a local PST file–this speeds up the data migration process and shortens the amount of time mail is unavailable for the source domain.
- Pre-stage the mailboxes, contacts and distribution groups in the destination tenant (using names in the destination’s vanity domain at first)
- You may add the accounts in the destination Active Directory and sync with Azure AD Connect, or
- You may add them to the destination tenant directly in the cloud, depending on requirement
- Note: you should make sure to capture properties such as aliases, group memberships and delegations also–the same will need to be added back in the destination
- When you’re ready to migrate the mailboxes, pause mail at the queuing service
- Migrate the mail data using a third party tool or PST export/import option (poor man’s method)
- Remove the vanity domain from the source tenant, which involves removing all references e.g. email addresses, aliases & SIP addresses, etc., and the primary domain name must be reset to the TenantName.onmicrosoft.com suffix instead of the vanity domain
- Add the vanity domain to the destination tenant, and update the users’ UPN/logon names accordingly
- In some cases, you may prefer to keep the UPN / logon names of the destination intact, and simply add the firstname.lastname@example.org as an alias on the account
- It may be necessary to restore legacy X500 addresses as well from the source domain (if applicable)
- Change the delivery destination to the new tenant at the queuing service and re-establish regular mail flow (also: once-over the other DNS records to ensure autodiscover, SPF, etc. look good)
- Test and ensure that everything is working properly
- Reconfigure Outlook clients & mobile devices to connect to the new mailboxes
- Optionally users can re-import the clean-up/archive file they were asked to create in step 2
And that’s just the process for email. Imagine how the complexity increases if the source tenant is also consuming other services such as OneDrive or SharePoint along with it. A lot of this has to be manually done (hence why Microsoft recommends a third party tool).
I wish I had a better recommendation here, or some slick trick involving hybrid, but I just don’t. Going through two migrations (off-boarding to an intermediary on-prem server) still poses some problems, particularly if the destination domain is already in a hybrid relationship with the other tenant. Seems like figuring out how to finagle something there would be more trouble than simply taking the poor man’s approach described above, at least for “SMB-sized” mergers & acquisitions (often companies of less than 50 users being acquired). This is why Microsoft recommends a third party tool.
If and only if…
If both orgs are in a “cloud only” configuration (no hybrid/directory synchronization present–and Exchange Online only), then it would be theoretically possible to:
- Stand up a dummy domain (add both alternative UPN suffixes for source & destination)
- Install Exchange Server on top of it (add the source domain to this server’s accepted domains list)
- Pre-populate the directory with user objects exported from the source 365 tenant
- Enable Azure AD Connect to synchronize with the source tenant
- Enable hybrid & offboard the source mailboxes to the temporary on-premises server
- Change MX/autodiscover to deliver on-premises (or use 3rd party SPAM/queuing service)
- Kill the hybrid relationship and remove the vanity domain from the source tenancy
- Add source domain to destination tenancy, and the destination domain to the on-prem server’s accepted domains list
- Synchronize all accounts from the on-prem server with Azure AD Connect
- Re-run the hybrid wizard for the destination tenant
- On-board the on-premises mailboxes to 365 using the Remote Move method, change MX/DNS records again
- Kill the hybrid relationship, remove Azure AD Connect, remove Exchange, remove temporary domain
Seems like a pretty rare and remote possibility for this scenario to work out (both organizations must not already be using Azure AD Connect/Hybrid Exchange). And even then, look how much extra work you’re doing–two migrations instead of one!