Multiple On-Premises or Office 365 Deployments in Post-Merger Integration

As Office 365 (O365) adoption has grown tremendously over the last few years, we see more and more companies leveraging it in some fashion. Even though many companies utilize Office 365, they still need help figuring out what to do to integrate IT infrastructure during Mergers and Acquisitions (M&A).

Given the nature of M&A, IT due diligence is often rushed, and IT professionals are given a short timeframe to come up with an approach for post-merger integration for the two organizations, so a good understanding of what the options are is critical for a successful project. With the current work from home landscape, a high level of complexity is added and needs to be considered when implementing a plan.

Because of all of the moving pieces that affect M&A scenarios, I have decided to shed some light on the process to make your company’s transition smoother. This blog is the first in a three-part series. This particular blog will cover M&A and post-merger integration from a high-level point of view. I will then take a deeper dive into a technical approach along with some of the “gotchas” we encountered along the way in parts two and three (so you don’t have to ).

Content

Let me start here by describing some of the most common scenarios you may be running into:

• Parent company on on-premises AD with O365 and Password Hash Sync (PHS) (or Pass-Through Authentication PTA)) -> Target company on on-premises AD with O365 and PHS/PTA
  • This is your typical Mid/Large to Mid/Large M&A. Both companies have been using traditional on-premises AD and have also transitioned services over to O365 in hybrid mode.

• Parent company on on-premises AD with O365 and PHS/PTA -> Target company on O365 cloud-only
  • A larger organization is acquiring an SMB/Mid-size company that has already gone through a complete cloud migration.

• Parent company on on-premises AD with O365 and PHS/PTA -> Target company on on-premises AD only
  • In this case, the target company has a lot of legacy on-premises apps and has not explored cloud-based solutions yet.

Once you understand the landscape of the target company’s infrastructure, you can start planning an approach to integrate both companies.

We typically classify approaches into two different buckets.

Co-Existence + Migration bucket

Due to the sheer amount of integration points between companies on the mid to large spectrum, it is often deemed necessary to set up co-existence capabilities between the two organizations to provide collaboration from the get-go (these types of integrations usually take 6-12 months+).

Out of the box, you will be able to use Azure AD B2B to ensure “external” users can be granted access to each other’s tenants. Additionally, you can also seamlessly federate Exchange to share calendars between organizations. Another critical piece to co-existence mode is making sure the Global Address List is shared across the two tenants. Although not supported natively, various tools in the marketplace can help you achieve this; we have had great success, specifically with the GalSync tool from CIRASYNC.

At the last Microsoft Ignite, several new features (currently in private preview) were announced, which will make the co-existence scenario more robust as we advance:

• Cross-tenant people search https://aka.ms/crosstenantpeoplepreview
• Domain sharing for Email, a domain that can be used in email addresses across multiple MS 365 tenants: https://aka.ms/domainsharingpreview

Once those initial steps are completed and that inter-tenant collaboration is happening, you can start tackling what the migration process will look like.

• Document all the target company’s services and capture versions, location (hosted/on-premises/cloud), data volume, and customizations. I will go into the specifics in my next blog for the items below:
  • SharePoint Online or On-premises
  • OneDrive for Business (ODFB) or On-premises “Personal” Shares
  • Corporate File Shares
  • MS Teams (Collaboration and/or Telephony)
  • Exchange Online or On-premises
  • Software as a service or On-premises Apps

Keep Tenants Separate (Co-Existence Only) Bucket

Keeping the acquired company’s environment separate from the parent company can be the outcome of post-merger integration driven by legal. In this case, the only viable option is to set up Co-Existence between the two tenants where possible based on the requirements. However, it is worth noting that multi-tenancy in Office 365 can be both complex and time-consuming to manage. The surface of attack will now have significantly increased due to the new identities and devices the organization must oversee.

In my opinion, once the collaboration pieces are in place, the greatest challenge to managing multiple tenants is security. I recommend leveraging a Security Information and Event Managers (SIEM) such as Azure Sentinel to ingest logs from numerous tenants and infrastructures into a single pane of glass.

The two-tenant approach is also sometimes used when a parent company starts a spinoff company or a new venture that must fully be separate from the parent. For this specific scenario, you will need to figure out whether it makes sense to go cloud-only for this new tenant or if on-premises AD access is still necessary (for legacy apps access on-premises, for example). This should also be seen as an opportunity to migrate any legacy file shares to the cloud (accessed by users on the new tenant). Starting a new deployment with on-premises AD + AAD/O365 hybrid model should only be used as a last resort due to its management and cost overhead.

Conclusion

These are just a few examples of the most common scenarios for M&A with Microsoft technologies and are by no means an exhaustive list of scenarios you may encounter during your IT due diligence and post-merger integration process. The combinations of infrastructures between parent and target companies are numerous, so getting the complete picture of the target environment along with a timely co-existence integration will set you up for success. As mentioned at the beginning, in my next blog, I will be writing a more in-depth technical approach for an M&A integration. Lastly, in the final part of this series, we will go even more into the weeds of the implementation, and I will share with you some of the “gotchas” I have encountered during past projects. Stay tuned!