These days it’s a common scenario to see a company acquiring another, and having both organizations hosting their email service in the cloud using Office 365. Unfortunately Microsoft doesn’t provide us with easy to use tools - and ways - to simply merge the two company’s cloud tenants, which gives other companies room to offer their cloud migration services, using their own proprietary software, which is probably a convenient way for system administrators but surely not ideal for mail flow or for the users. They technically offer their proprietary software to connect to both organizations, create the corresponding new mailboxes in the target tenant, copy the data over and after a final synchronization they remove the source mailbox and finalize the target. Now the first of the two biggest problems with this approach is that we need to purchase extra licenses for the target tenant to accommodate the new mailboxes until the other tenant is demolished and those licenses can be transferred over: it’s inconvenient, costs extra and it’s hard to rely on Microsoft to make the transfer fast – which can be delayed by many things. The other thing is the fact that we cannot have the same domain name in two tenants at the same time, you can’t use the source company’s existing email addresses on the target tenant until all of the mailboxes are migrated over and the domain is removed from the source.
Luckily with a little effort there is a way to maintain perfect mail flow during the migration while users are able to use their original email addresses, the same mailbox profile in their Outlook, with no need to purchase extra licenses not even temporarily and with this method we only use the built-in functions of Microsoft EOL and Exchange 2013.
So enough talking, let’s jump into it!
This guide simulates a scenario where a company called “Jd0e Inc” (in our case) was acquired by “Agzsolt Inc”. They both use a hybrid Office365 environment, in this guide we focus on the email service. Our goal is to merge Jd0e into the Agzsolt tenant while we maintain mail- and workflow the whole time.
To make the situation a little more complex, the source Jd0e tenant is using ADFS for single sign-on functionality. Also the Jd0e users are still using the old 2010 version of Outlook so we stick with it here.
In our example agzsolt.com is the destination tenant and jd0e.com is the organization to be moved the mailboxes from.
The starting scenario
Destination:
agzsolt.com
Hybrid
O365: agzsolt.onmicrosoft.com tenant. agzsolt.com is the default domain
Onprem: Exchange 2013 CU18 server: 51.143.185.87
Source:
Jd0e.com
Hybrid and ADFS federated
O365: jdoe.onmicrosoft.com tenant; jd0e.com as the default domain
Onprem: Exchange 2013 CU18 server+DC: 51.143.157.86
Adfs proxy: 51.143.188.208
As expected, the incoming emails are directed to the corresponding on-prem mail server, where they are forwarded into the cloud if the target mailbox is not found locally with the help of to the hybrid setup. To visualize the mail flow now:
Mailbox situation:
Destination – agzsolt.com:
Source – jd0e.com:
Prepare the destination on-prem server
- Add jd0e.com to the accepted domain list
2. If not already done, create a Send Connector for the cloud
