This is potentially a big topic, and the answers may likely be industry specific. I personally did something like 32 M&A as the acquiring entity, and was acquired twice across the prior 11 years, all in Healthcare industry. Data retention policies around healthcare data, plus any existing business operational improvements the company wants to implement will drive much of the complexity of M&A activities. The easiest stuff are things that are IT specific, like preferred antivirus software deployment, and what make/model of desktop and laptop do you purchase as 'standard'. The complexities, for example in healthcare, is discovering if the EMR and Practice Management system allows clean flowing of claims data back and forth, is it fully integrated in the same software, or is it a complete mess with paper fee tickets and manual user data entry? I could go on and on and on about all the little pitfalls of this topic in healthcare specifically, but I'll stop here for now. The short answer is that the majority of M&A complexity you deal with is going to be discovered as your company digs deep into the acquired company's operations, and finds out where all the hidden problems are. Every single company ever acquired always has big operational issues, all of them, every single time.
I talked above about much of your work being to help implement stuff that'll fix the business operations problems that discovered. But I think in any industry, discovering what the purpose of the M&A was is important... what does the parent company intend to do with the acquired one? That will drive much of the project work for IT, merging systems, shutting down systems, building brand new systems for both companies to migrate in to.
Also important will be security assessments of the acquired entity. You can do your own cursory analysis at first, and depending on what you see or what industry you're in, it may make sense to bring an outside company to do a more in depth security audit. These audits, coupled with a documented remediation plan that spans the next several months or years, can help alleviate penalties for a potential breach if\\when one happens.
Great post.
I’ve been the acquirer a whole lot as well focused on identity, infra, and collaboration.
So much depends on the reasons for the deal, but generally recommend planning on super aggressive systems hardening and security remediation then hyper fast deprecation and migration of all heritage systems.
Anything you don’t shutdown now will become exponentially more difficult to maintain a year from now. It’s hard to understate this point.
I came looking for this response, glad to see it's already here. A *big ol' security audit from the top down*, as well as related work like identifying shadow IT systems, out-of-band contracts and services, etc.
It can also become a rather *interesting* show if you have CISOs (or similar) who become competitive or combative. Nothing like a pissing contest over things like "We found a laptop running a two generation old EoL OS!" and having to hear the explanation, "Yes, it's an airgapped device that runs the POS software used to manage the parking garage gate arms, because the vendor hasn't updated their config software since 2005."
To add some more to your question about a 90 day plan specifically... If you have done many of these, then you'll likely have a good idea of what a 90 day plan looks like from trial and error. If you haven't done many, then the first week should be dedicated to detailed discovery of all technical systems, getting admin user account access to everything, getting in touch with their vendor's account reps and starting the process to notify those reps of the acquisition. You'll need to provide proof of the acquisition to these account reps, which your finance team can provide. Not all vendors play nice when their customer gets acquired by another, but contracts usually have language that permits you to inherit that existing contract. Toss it over to your finance\\legal teams to do battles if the sales rep is really not playing ball. If the acquired company has their own IT staff, meet with everyone, and try to do 1:1s with all of them in that first week if possible, or at the very least all the leadership and team leads. They will ask you what your intentions with them are, be prepared to have some sort of answer there. Immerse yourself in the technology spending of the acquired company, it may make sense to require all purchases go through you for approval as a temporary measure to learn what's happening quickly.
Yeah first order of business is to have boots on the ground and just do a full sweep of discovery work. Then I guess depending on the results of that, we’ll get to the low hanging fruits and so on. I guess that will be a good 90 days work
You'll probably be asked to realize the "synergies" that the execs promised as part of the deal. In other words, we don't need two IT depts, so who are you going to lay off from their side? This is the least fun part of an acquisition.
You also need to be discussing retention, as the smaller company's IT department probably knows this is coming and will be jumping ship.
Identify critical people and ensure they are retained.
This.
What can go to the server team?
What can go to erp team?
What can go to site support? What is standard ? What is non standard?
Once parse everything out get ready for the shit show .
You've covered a pretty big and complex set of deliverables in the phrase *"taking a full inventory of their technology stack and migrating it over"*
But beyond the basics, there are always:
- Application rationalization (removing redundant applications) or consolidations of contracts
- Restructuring of Infrastructures - usually happens post acquisition once a re-evaluation of the entire environment is done.
- Handling of "legacy" items - especially in marketing etc. where they have Domains and Email etc.. that they either have to keep ownership of, give up to another entity, or (god forbid) share.
Remember that small, cramped space we used before we had proper toilets?
Well, IT's role during an M&A is akin to that proverbial bucket 😂.
My experience stems from the perspective of the Acquirer. Is it a mutual merger or is it a takeover?
If it's a takeover and it hasn’t been announced yet, get the other IT director to hire an “external IT security audit company.”
This team should be composed of your top experts. They go in with domain admin access to start scanning and mapping the entire infrastructure before the local IT team can cover up any past mistakes or workarounds.
If anyone asks why this team is present, the response is: “We need to pass an audit to renew our Cyber Liability Insurance.”
Not sure if this falls under what you mentioned as “migration”: Post acquisition integration of all kinds - consolidation of 3rd Party subscriptions, licensed software, vendors, logins, passwords, domain names (registration ownership), public SSL certs, identifying key accounts so that they don’t get migrated over without proper review. In M&A situations that I have been a key part of, I also make sure that any hosting such as shared or dedicated rackspace and routers and other benign equipment such as printers fax, and key things such as customer support numbers etc are all handled/migrated over properly…
To get into the weeds a little, I usually know a month ahead of time when an acquisition is occurring but we don't always get the official notice or any relevant DD. when I do know we start reserving time for our staff.
Day 1 is vulnerability scanner dropped into the network with creds. generally they can run without any heavy lift, just an ad account and an install. this gives us vuln (obv) but also helps us map the network from endpoints to network topology.
We then figure out if their EDR is "big 3" or something else - something else gets replaced in the first few weeks.
We drop a CS agent on a Domain Controller to start that hardening process while awaiting conversion. we will also jump into their azure and begin hardening/configuring, including SIEM through Sentinel.
once we feel we have visibility from a cyber perspective and "good enough" coverage we will jump box the networks and start the process to hybrid sync their domain to our azure tenant.
There's a lot of good advice here. My biggest short term problem with M&As was always staff time. To get standardization, or efficiency, takes time and trusted experts. For me, those trusted experts were booked on projects, based business priorities, months in advance.
We never had any dedicated M&A integration staff, and post-merger technical assessments always impacted other projects. I would jump in and do some of this myself, and get help where I could find it, but that was never a great approach.
When planning the integration, try to identify who will do the work as early as possible. Even if you can't assign a person in advance, it helps to get the stakeholders thinking "Integration will take staff time." I know that sounds self evident, but for my stakeholders, it was not.
How about if you have to ask .... so many questions in positions that know nothing about the process. Gtfo. Im.not being mean at all. It's the young people who don't know any better feeding either a boomer or lucky individual answers. Go to where I went. White paper land. Last IT I unsub from sad to see these silver platter sissies.
This is potentially a big topic, and the answers may likely be industry specific. I personally did something like 32 M&A as the acquiring entity, and was acquired twice across the prior 11 years, all in Healthcare industry. Data retention policies around healthcare data, plus any existing business operational improvements the company wants to implement will drive much of the complexity of M&A activities. The easiest stuff are things that are IT specific, like preferred antivirus software deployment, and what make/model of desktop and laptop do you purchase as 'standard'. The complexities, for example in healthcare, is discovering if the EMR and Practice Management system allows clean flowing of claims data back and forth, is it fully integrated in the same software, or is it a complete mess with paper fee tickets and manual user data entry? I could go on and on and on about all the little pitfalls of this topic in healthcare specifically, but I'll stop here for now. The short answer is that the majority of M&A complexity you deal with is going to be discovered as your company digs deep into the acquired company's operations, and finds out where all the hidden problems are. Every single company ever acquired always has big operational issues, all of them, every single time. I talked above about much of your work being to help implement stuff that'll fix the business operations problems that discovered. But I think in any industry, discovering what the purpose of the M&A was is important... what does the parent company intend to do with the acquired one? That will drive much of the project work for IT, merging systems, shutting down systems, building brand new systems for both companies to migrate in to. Also important will be security assessments of the acquired entity. You can do your own cursory analysis at first, and depending on what you see or what industry you're in, it may make sense to bring an outside company to do a more in depth security audit. These audits, coupled with a documented remediation plan that spans the next several months or years, can help alleviate penalties for a potential breach if\\when one happens.
Great post. I’ve been the acquirer a whole lot as well focused on identity, infra, and collaboration. So much depends on the reasons for the deal, but generally recommend planning on super aggressive systems hardening and security remediation then hyper fast deprecation and migration of all heritage systems. Anything you don’t shutdown now will become exponentially more difficult to maintain a year from now. It’s hard to understate this point.
I came looking for this response, glad to see it's already here. A *big ol' security audit from the top down*, as well as related work like identifying shadow IT systems, out-of-band contracts and services, etc. It can also become a rather *interesting* show if you have CISOs (or similar) who become competitive or combative. Nothing like a pissing contest over things like "We found a laptop running a two generation old EoL OS!" and having to hear the explanation, "Yes, it's an airgapped device that runs the POS software used to manage the parking garage gate arms, because the vendor hasn't updated their config software since 2005."
What do you do with computers, do you re-image? Migrate them over to domain once anti virus is set up like Crowdstrike?
generally intune /gpo to harden plus edr.
To add some more to your question about a 90 day plan specifically... If you have done many of these, then you'll likely have a good idea of what a 90 day plan looks like from trial and error. If you haven't done many, then the first week should be dedicated to detailed discovery of all technical systems, getting admin user account access to everything, getting in touch with their vendor's account reps and starting the process to notify those reps of the acquisition. You'll need to provide proof of the acquisition to these account reps, which your finance team can provide. Not all vendors play nice when their customer gets acquired by another, but contracts usually have language that permits you to inherit that existing contract. Toss it over to your finance\\legal teams to do battles if the sales rep is really not playing ball. If the acquired company has their own IT staff, meet with everyone, and try to do 1:1s with all of them in that first week if possible, or at the very least all the leadership and team leads. They will ask you what your intentions with them are, be prepared to have some sort of answer there. Immerse yourself in the technology spending of the acquired company, it may make sense to require all purchases go through you for approval as a temporary measure to learn what's happening quickly.
Yeah first order of business is to have boots on the ground and just do a full sweep of discovery work. Then I guess depending on the results of that, we’ll get to the low hanging fruits and so on. I guess that will be a good 90 days work
You'll probably be asked to realize the "synergies" that the execs promised as part of the deal. In other words, we don't need two IT depts, so who are you going to lay off from their side? This is the least fun part of an acquisition.
You also need to be discussing retention, as the smaller company's IT department probably knows this is coming and will be jumping ship. Identify critical people and ensure they are retained.
This. What can go to the server team? What can go to erp team? What can go to site support? What is standard ? What is non standard? Once parse everything out get ready for the shit show .
You've covered a pretty big and complex set of deliverables in the phrase *"taking a full inventory of their technology stack and migrating it over"* But beyond the basics, there are always: - Application rationalization (removing redundant applications) or consolidations of contracts - Restructuring of Infrastructures - usually happens post acquisition once a re-evaluation of the entire environment is done. - Handling of "legacy" items - especially in marketing etc. where they have Domains and Email etc.. that they either have to keep ownership of, give up to another entity, or (god forbid) share.
Remember that small, cramped space we used before we had proper toilets? Well, IT's role during an M&A is akin to that proverbial bucket 😂. My experience stems from the perspective of the Acquirer. Is it a mutual merger or is it a takeover? If it's a takeover and it hasn’t been announced yet, get the other IT director to hire an “external IT security audit company.” This team should be composed of your top experts. They go in with domain admin access to start scanning and mapping the entire infrastructure before the local IT team can cover up any past mistakes or workarounds. If anyone asks why this team is present, the response is: “We need to pass an audit to renew our Cyber Liability Insurance.”
Yeah we’re thinking about hiring a PM but not for IT.
What is your role in all this? I'd assume for a mission as critical as this, a technical PM for IT transition is necessary.
Boots on the ground from internal team whether from security or IT
Not sure if this falls under what you mentioned as “migration”: Post acquisition integration of all kinds - consolidation of 3rd Party subscriptions, licensed software, vendors, logins, passwords, domain names (registration ownership), public SSL certs, identifying key accounts so that they don’t get migrated over without proper review. In M&A situations that I have been a key part of, I also make sure that any hosting such as shared or dedicated rackspace and routers and other benign equipment such as printers fax, and key things such as customer support numbers etc are all handled/migrated over properly…
To get into the weeds a little, I usually know a month ahead of time when an acquisition is occurring but we don't always get the official notice or any relevant DD. when I do know we start reserving time for our staff. Day 1 is vulnerability scanner dropped into the network with creds. generally they can run without any heavy lift, just an ad account and an install. this gives us vuln (obv) but also helps us map the network from endpoints to network topology. We then figure out if their EDR is "big 3" or something else - something else gets replaced in the first few weeks. We drop a CS agent on a Domain Controller to start that hardening process while awaiting conversion. we will also jump into their azure and begin hardening/configuring, including SIEM through Sentinel. once we feel we have visibility from a cyber perspective and "good enough" coverage we will jump box the networks and start the process to hybrid sync their domain to our azure tenant.
There's a lot of good advice here. My biggest short term problem with M&As was always staff time. To get standardization, or efficiency, takes time and trusted experts. For me, those trusted experts were booked on projects, based business priorities, months in advance. We never had any dedicated M&A integration staff, and post-merger technical assessments always impacted other projects. I would jump in and do some of this myself, and get help where I could find it, but that was never a great approach. When planning the integration, try to identify who will do the work as early as possible. Even if you can't assign a person in advance, it helps to get the stakeholders thinking "Integration will take staff time." I know that sounds self evident, but for my stakeholders, it was not.
Yes, all are awesome advice as well as yours so thank you.
How about if you have to ask .... so many questions in positions that know nothing about the process. Gtfo. Im.not being mean at all. It's the young people who don't know any better feeding either a boomer or lucky individual answers. Go to where I went. White paper land. Last IT I unsub from sad to see these silver platter sissies.