Forum Discussion
John Jessee
Nov 18, 2018Copper Contributor
Onboard acquired company to existing O365 tenant
We recently acquired a company. I need to onboard their emails to our existing O365 tenant. Here are the details:
CompanyA: Office365 with Azure AD connect with password sync - 120 users
CompanyB: On-Premise Exchange 2013 - 220 users
We have a trust relationship between the forests in place. We will eventually combine both companies into one forest, but that will be at a later date.
What would be the best path to onboard CompanyB to the CompanyA Office 365 tenant? I must have password sync for all users. I don't want to have any on-premise Exchange servers when all of this is finished.
Thanks for any guidance.
John
Hey John,
I have to deal with the exact situation fairly often.
One of my clients is an Oil and Gas company, and acquires new companies with pretty good regularity, so they are always having to look at what is the right step to move users into their O365 tenant.
A few thoughts:
1. Hybrid is the best and most complete migration. That is why you are going to see so many people suggest it.
2. Hybrid requires that the Active Directory be setup so that users can be discovered and managed properly on both the on-prem and O365 system. This particular issue becomes increasingly messy as you grow and acquire more companies.
3. Azure AD connect - Supported typologies - bookmark this link now, you will need it allot over the next few mergers
acquisitions- https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies
4. If this is going to be a re-occuring thing, for the love of all things holy, decide Active Directory matters way more than the people around you are realizing, and developing a comprehensive and clear plan around your AD, specifically around some sort of consolidation of your AD, is in your long term favor.
5. If you dont have the staff, money, or time to do hybrid and AD the right way, dont kid yourself into thinking you can. You are going to create a much worse situation that you cant climb out of half assing a deployment of that complexity if you dont have the resourcing needed to pull it off. The cheap "work around" option is listed at the bottom.
If i have a client come to me with the scenario you are describing, to me step 1 is figuring out what your "end state" active directory is, and doing the work NOW to setup for that success. Hybrid and specifically mergers are such a huge pain in the butt without a unified AD. So if you can say "we are putting the effort into moving everything into one AD, holy god that saves you time and heartache." If you cant...... (more below)
For the first move, I would look at adding in your new companies AD as a separate forest. As long as each object is only listed once, you can then use the one Azure AD connect server to your O365 tenant and make this work. (Start reading at - Multiple forests, single Azure AD tenant).
Once your AD is setup correctly, you then can look at setting up hybrid with the 2013 system with your newly acquired company. That makes your first migration somewhat easy. You follow the O365 hybrid migration path, you are just starting with 120 already cloud users.
*Side note, if you plan on staying in a "hybrid" state, you really need to consider adding your cloud users back as Remote Mailboxes to the 2013 system, and fully merging your AD's. If you dont, how you manage users from company A, and users from Company B is different. Furthermore when company C comes along, you are then either unable to do a hybrid (because you are already hybrid with company B's server) or have allot more work before a move is possible.
The issue you have here, is now any new migration has to be added into your hybrid enviroment. You can never again just "bolt on" a system like we would for the first migration. You are "lucky" in that your current setup is not hybrid. So doing the first move is easier. For the move of company C, you are looking at a much more complex path to merge all parties involved.
OK now with that laid out on how to attack your first migration. What end state looks like afterwards etc, lets talk about the "least investment" path that most of my clients took because taking on an entire AD re-architecture was too much. Allot of people do the first move as described above, then for C and on do the non-hybrid move.
1. The Non-Hybrid migration - My fellow exchange purists are rioting right now, as these migrations are much more clunky, way more impacting to the user, and just "old" compared to the ease of a hybrid migration. BUT your AD doesn't matter here. Use something like Bittitan's Migration wiz to move over calendar/contact/mail data for the users into new accounts. Have those accounts be populated by adding a "connector" to your existing azure ad connect server from the second AD. That connector will add in another domains users into O365, and then since you are not doing hybrid you just need to license/migrate the data, then switch over DNS records to use O365.
This is way easier than the other models, and 99% of the time is what my clients did. It is way more impacting to the end user. You have to re-setup mail profiles, they lose categories, etc etc. But topology wise, and end state wise, its just such a less investment of time and effort on your part, its what most of them do.
Hope this helps, if you have any questions you can let me know, or send me a PM.
Adam
- I would start planning a migration from Exchange 2013 to EXO by means of the hybrid method what implies you will need also Azure AD Connect at Company B something possible as long as you have one of the supported topologies in place: https://support.office.com/en-us/article/use-mail-merge-to-personalize-letters-for-bulk-mailings-d7686bb1-3077-4af3-926b-8c825e9505a3
- John JesseeCopper Contributor
I’m not really sure what that link has to do with this subject.
He was probably cross-posting on another topic :) I agree though, if possible setup Hybrid and use the native tools to migrate the mailboxes. There are tons of materials available on the subject online, I suggest you start with reviewing the steps from EDA here: https://docs.microsoft.com/en-us/exchange/exchange-deployment-assistant
If for whatever reason Hybrid is not applicable to your scenario, your best bet will be 3rd party tools, but those usually come at a price.