Migration Scenarios for Mergers and Acquisitions

M&A and Divestitures - The business context

For mergers and acquisitions, you are integrating one organization into an existing organization, or merging two organizations into a new organization and taking the best of both worlds. You need to In most scenarios the organization already has some of the infrastructure in place, HR, Finance, Facilities. On the negative side there is often some redundancy, and it is difficult to figure out what stays and what goes.

For divestitures, we are selling a business unit to become a new standalone organization or transitioning it to another existing organization. Some positives would be a new organization opens an array of possibilities, whereas negatives would be less-defined processes and the potential need to build from the ground up.

One thing to note. This advice only references SharePoint and Teams. Exchange is its own thing and often is a separate project. We are speaking here mainly about the intranet/collaboration sites and how best to approach that scenario.

Typical Steps

Regardless of which direction you’re going, we strongly recommend that you do content inventory first. For example, how many sites do you have? What is the breakdown of communication sites vs team sites? What types of content is there and how much of it is there. This helps determine what sites will be heavy lifts vs. simple migrations. It is also important to do a solution inventory, especially for a tenant where there’s been a lot of custom development and there are things in the app catalog either internally developed or third-party solutions. An inventory of users should also be done to determine who the involved people are in this different reorganization and who maps to what domain.

Common Nuts and Bolts

We must have our users figured out for M&A or divestitures. From the M&A perspective, company A bought company B. It’s important to make sure that the company B users are created in company A before we start migrating content. We move the content over with whatever tool, we mostly use ShareGate. We must make sure the new users are created and that we’ve got a mapping somewhere. This makes sure that we don’t loose version history and traceability for content even if those users don’t end up working or leaving company A.

From the divestiture perspective, it will be the other way around. Company A has a thousand users and company B is going to be split off into 100 users, we need to know who those 100 users are. Either way, the user bit will need to be understood.

For information architecture, if you are bringing things in, you want to know what the destination information architecture is and make sure that if you want to make any changes to your stuff when it comes in, you do that. If you’re divesting, it’s a chance to figure out some things you wish you hadn’t done that you can do differently. It is a chance to start fresh!

Lastly, it’s important to get your business users involved as early as possible to test how the migration is going. We know the technology, we know the mechanics but the business users know the content which is important.

Divestitures - Technical nuts and bolts, and lessons learned

We have to create a new tenant from scratch, with company A being very large, a thousand people, and company B is being divested out into its own entity. We will now have to come up with company B’s tenant, including namespaces, automation for site creation, flows and power apps, etc.

M&A - Technical nuts and bolts, and lessons learned

The idea here is to have a small little company, and then a big company buys and acquires the small company. So what does and doesn’t work? If you have custom code it’s important to review that code and make sure it was done correctly and that there are no hard coded tenant names or URLs in there. You want to make sure you look for security issues. Don’t just bring the data over, instead check out templates.

Keep in mind, whether it’s an M&A or divestiture or any kind of migration piece, it’s an inflection point for you to look at what’s going on with everything from your content, your site templates, your document templates, your information architecture. Do a review and see what is working and what isn’t. Look at the content to see whether or not it’s being used and if it meets your needs because there’s always going to be something that’s working and something that’s not. Resist the urge to just “Lift and Shift”.

Things to do before a migration

  • Run a Pre-Check using your migration tool
    • This catches errors and issues before you start migrating a TB of data.
  • Create the old company users, even if they’re gone
    • This ensures you keep a consistent version history on documents even for users that are no longer with the company. Delete these users after the migration is complete.
  • Create a test site and do the migration into that first
  • If you have classic sites migrate them. Modern is the supported user interface now. Take this opportunity to reduce the technical debt at the start.

References

Do you have any questions for us? Continue the conversation on Twitter with the hashtag #AskSympraxis and mention @SympraxisC.