M&A Strategy with Microsoft 365 / Office 365

I’ve been working with companies going through mergers and acquisitions for years.  They are painful and take a lot of investment to get right.  The better transitions are proactively managed on the tech side and include time and effort to improve the operational state of both organizations.  As tech modernization has happened over recent years, there have been a lot of changes and/or improvements to the M&A strategies.  Here are just a few of the ways I’ve come to appreciate the acceleration possible.

STAGE 1: WORKING TOGETHER

Collaboration with Federated Office 365 tenants

The biggest immediate benefit is how quickly companies that are both on Office 365 can start collaborating securely by leveraging inter-tenant sharing.  This is compounded by new Teams features announced at Ignite that further allow collaboration between existing tenants.  Right after an integration is announced the companies can start collaborating on key assets without emailing them around, each being able to co-edit the same documents and work within the same Teams environment.  This has had drastic effect on the ability of companies to work well together.

The primary activities done here are:

• Create governance policies tied to M&A teams
• Share content from Teams directly vs. emailing the document
• Facilitate staged availability of chat as awareness exists to business change
• Apply rights management to critical documents before M&A announcements
• Create shared working environments in Teams or even channels

The “Secure the Asset” stage can be accelerated

An initial phase of M&A is “secure the asset” where the goal is to assess an acquired company, define an improvement strategy, create a plan for integration, and know the immediate gaps.  A historical challenge is that legacy environments needed to go through a domain migration, etc. in order to get governance from the acquiring business.  This is not the case moving forward, where cloud-based management tools can be quickly deployed to all devices while the device stays on the legacy Windows Active Directory domain.  The ability also to extend policy management for the cloud environment across multiple tenants provides increased certainty of the target environment.  This is of course dependent on the acquiring environment having mature cloud endpoint management and cloud governance.  If that doesn’t exist, then the M&A is likely an opportunity to build that out.

The primary activities done here are:

• Extend the cloud endpoint management across the ecosystem, despite separate domains
• Extend the governance over the cloud estate at minimum for policy adherence validation
• Assess the estate for clear security gaps prior to movement
  

Identity Integration Aided by Birthright Driven Provisioning

The best practice for identity provisioning is that the employee system of record is the governor of who exists in the identity platform.  This can be used quickly to give new users access to resources in each company, or even to establish the provisioning of all the users in the new environment. 

The primary activities done here are: 

• Employee data platform(s) (ADP, Workday, Spreadsheet) retains list of users
• Provisioning process creates identity(s)
• Identities provide access to HR platform and other applications via “birthright access”
• Specialized identity granted via role in the company (may be 1, or thousands)
  
   

The M&A process can use this by prioritizing one or more source HR platforms to approve the creation of the users in the new directory system.  The identity provisioning can then be used for the necessary migration activities from Office 365, applications, end user computing, and other platforms.

Immediate Onboarding with Azure Virtual Desktop or Windows 365

The teams can immediately start doing work in a new world with Azure Virtual Desktop, even from their existing computers in an older Windows Active Directory domain.  The solution is often giving the user another computer to use to access the new resources.  Instead, we can manage that by granting AVD access, temporarily or permanently.  We’ve frequently used this to provide immediate access for new users to financial tools or business apps.  The extension of management to the devices can also make this access more secure, since conditional access can be applied to the user. 

The primary activities done here are:

• User’s identity is provisioned from the identity flow above
• User is positioned inside a group that provides access to the critical apps
• User can access new critical apps from their old device
• Security controls are applied to the new AVD via conditional access and work done in “secure the asset”
• The AVD could even become the “primary” system the user leverages, with other content converted later during the actual migration
  

STAGE 2: MIGRATION

Content Migration Aided via Tenant to Tenant Tooling

The big step is getting content migrated to the new tenant.  This is typically made possible via a set of tenant-to-tenant synchronization & migration tools.  The user content in this case needs to be synchronized to the new target. Typically it is staged and then a migration date is picked. In most cases it needs to move together, in some cases you can parse it out based on the scenario.

The primary activities done here are:

• OneDrive content synchronized and staged
• Email content synchronized and staged
• Teams content synchronized and staged, including history
• SharePoint content (esp. that tied to Teams) synchronized and staged

The preparation of this content is then combined with the next step of deploying a new Modern Desktop device for the user, or by migrating the existing device to the Windows Active Directory domain. 

File Server Content Migrated into Office 365 or Azure Files

Yes, you could migrate the file servers and the devices on the Windows Active Directory domain and establish connections to the new targets.  That said, WHY?  Instead of bringing along the tech debt, use this opportunity to largely eliminate the file servers, move the content into Office 365 and Azure Files, allowing for a clean destination environment.  The constant reminder of historical tech debt indicates this is the right move.  Yes, you’ll experience potential issues and some will indicate that this “cannot be done”.  I’ll say, now is the time to address the file server problem and improve the supportability of the destination environment.  Ask yourself “why am I consolidating two IT environments?”  The reason is to ensure adequate security and gain economies of scale.  Take a moment and draw a line in the sand that file servers are not going to be migrated and that your destination environment will contain only what is considered the supported environment.

The primary activities done here are:

• Migrate file server content to the new Office 365 tenant or Azure Files
• Provide access to target content in the new Office 365 tenant to legacy users

Re-Deploy Endpoints with Autopilot for Fresh Experience with Modern Desktop

There are two schools of thought for M&A.  The first aims to move the user to the new environment with “do no harm”, with a goal of minimizing the impact of the change on the user.  This conversion process follows the typical M&A playbook, where user devices are migrated to a new Windows Active Directory domain.  The conversion process brings along content from the device and aims to minimize the impact on the user.  This process doesn’t solve packaging or support issues and instead inherits a great deal of tech debt for future remediation.   The process also gives the user false expectations surrounding how minimally impactful the migration will be.  The fact is that migrations rarely have little user impact and most often cause lots of little inconsistencies and challenges despite the migration team’s best efforts.  The modernization of tech brings another option to the forefront, at least for *some* of the migrated devices, which is to move the end user computing devices straight to Modern Desktop. 

The primary activities done here are:

• Devices are migrated to Azure Active Directory only, not Windows Active Directory
• Devices are intentionally kept off the Corp-Net on the new environment
• Devices are refreshed and user content moved prior to cloud environments
• Applications are packaged prior and content moved prior to the device refresh itself
• The end state of the migration is a user with a fresh device feel

Migrating Legacy Applications to Destination Windows Active Directory Domain

The legacy applications will still need to be migrated to the Windows Active Directory domain.  The elimination of the file servers will certainly aid the efficiency of the process, but we do still need to eliminate the dependency on the source domain.  The future state goal to migrate the legacy servers and applications to the new domain persists and will either be accomplished by (1) completely re-deploying applications into the new domain as needed (appropriate for very small environments), or (2) using a migration toolset to migrate the servers to the new Windows Active Directory domain. 

The primary activities done here are:

• Migrating legacy servers to the new domain is still necessary
• This can be done in conjunction with other migration activities
• Usually facilitated by a trust and tooling (like Quest)

Migrate the Legacy Applications to Azure and Minimize the Distributed Datacenters

The legacy application servers can be migrated to Azure at any time, but the typical stage is either before or after the identity conversion is completed.  The ideal path is to eliminate as many servers as possible (such as via migrating the file content to Office 365), then moving the remaining servers to Azure before or after the identity change.  This change also normalizes the operational state of the migrated server in the managed Azure environment.  Until this change is performed it is best to consider the server environment at risk, since organizational policies may not have yet been applied.  The alternative state could be that BOTH environments were already moved to Azure.  In this case, a migration likely is NOT necessary, since the tenant could be captured under the acquiring company’s tenant.  The goal would be to apply policies across the environment to the servers. 

The primary activities done here are:

• You can move the servers to Azure at any time
• Validate that the migration is done within a CAF landing zone
• Apply infrastructure-as-code, micro-segmentation, tagging, backup, and cost management

Throughout the process of starting to work together and ultimately migrating my number one recommendation is to use this as an opportunity to optimize the environment. In most cases the optimization is not a blocker to actually getting the work done. It’s just a remediation of being lazy and avoiding doing work that will be tech debt later. Activities like moving to Modern Desktop, migrating to Azure, implementing modern collaboration tools are just things you’ll need to do later without the access to budget and engagement. You’ll be involved in a new crisis or new growth that will make the historical remediation that much harder. Do it now and do it right.

Nathan Lasnoski