SOLVED

Onboard acquired company to existing O365 tenant

Copper Contributor

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

11 Replies
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-d76...

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.

I'm pretty solid on migrating to Office 365.  I've just never found an official Microsoft whitepaper or tech paper on how to deal with this topic.  I need to know that this is a supported method by Microsoft for management reasons.  I have found the supported Azure AD connect topology documentation, but not a migration document.

You dont currently have Exchange in the first organization, right? If so, it's effectively a single-forest Exchange Hybrid migration and it's supported. At best you will have to play a bit with the sync rules.

I thought that the hybrid migration required a machine joined to the domain that Exchange is on (CompanyB) for the Azure AD Connect and hybrid migration wizard.  I already have an Azure AD Connect machine on the CompanyA domain.  Or can I use the current Azure AD Connect machine to do the Hybrid migration since we have a trust relationship between forests?

Also, we will be adding several more hybrid setups as we acquire additional companies.  I just want to make sure I'm not going to break something.

best response confirmed by John Jessee (Copper Contributor)
Solution

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

Adam.  Thanks for the information.  I have thought about the Migration system from BitTitan.  Didn't know if it was worth the money.  At the end of the day I need as little downtime as possible and I need the ability to grow fast.  I can handle the AD part.  We are in the middle of cleaning that part up right now.  I'm just not confident with the hybrid migration as we continue adding additional companies into the system.

 

The management team is insisting on getting everyone on Office 365 NOW.  I told them that we can do it, but it will cause more work later.  They are fine with that.  So we will do the unified AD next year and deal with the headaches of that later.  Not my choice.

I have my second forest added to the Azure AD Connect.  Sync worked the first time after fighting getting it added.  I had an old version of Azure AD Connect and needed to upgrade.  I will be using the Bittitan migration system.  I have no clue why Microsoft can't provide a similar system.  Thanks for all the input.

Hey John,

 

They are working on improving them dont worry!

They announced not too long ago they are developing their own system just for Google migrations that will basically do everything the bittitan one does. I would think it would not be too long after they expand that to other IMAP connections as well.

 

Glad its working for you!

Adam

1 best response

Accepted Solutions
best response confirmed by John Jessee (Copper Contributor)
Solution

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

View solution in original post