How much effort should go into configuring the technology stack during the due diligence phase of an acquisition?

502 views5 Comments

CIO Strategic Advisor in Services (non-Government), 2 - 10 employees
I've been through the acquisition process end-to-end many times. In one organization, we averaged one per month. What you want to do and what you can do are two vastly different things. You may want to dig into the technology, but unless it’s a core tenant of that acquisition or merger, you can’t reach the level of depth that you'd like to. It'd be great to get into that if we had the time and resources and it was appropriate to do, but you have to weigh that against how material it will be to the transaction itself. How much of an impact will the tech have on the transaction? And are these things that we can manage as part of the integration phase, as opposed to dealing with it upfront as part of due diligence (DD)? If you're part of the core DD team, you go through a tiered process. I was, but most CIOs aren't.
CEO in Software, 11 - 50 employees
Acquisition is a different game depending on whether you are acquiring customers or technology. If you're acquiring a company for customers, then there's a much greater focus on how the two organizations are going to live together from a shared technology standpoint. If we're acquiring someone because they have better technology than us, or they add to our portfolio as a sales or product development opportunity, then it's very hard to get C-level executives to focus on the minutiae of the integration. All they care about is getting that technology as soon as possible, no matter how hard the CIO has to work later.

What if the acquired company includes someone who runs the exchange/active directory, which we don't use? If I don't tell them to adapt what they’re doing to our platform before the integration, and then I ignore them for six months post integration, they’ll be building responsibilities and connecting applications to their active directory and exchange environment. That makes it a much harder fix in the future. 
1 1 Reply
CIO in Finance (non-banking), 51 - 200 employees

The IT department won’t have much influence when the company’s capturing engineers either. We could say, "They don't have SSO." Executives are not going to care. They’ll tell you, “We're still grabbing these engineers no matter what you say.”

Director of Technology Strategy in Services (non-Government), 2 - 10 employees
The question that should drive the whole process is: Why are we doing this? Are we acquiring this company for access to their customer book? Are we acquiring them for their products? Because the answer to that will dictate how much due diligence you should do on the tech stack. If you're just buying a customer book, you can assume that the tech stack is not the important thing. But if you are buying them for a product that they're manufacturing, the technology behind that might be of more importance.
Director of IT in Software, 201 - 500 employees
It depends from acquisition to acquisition. I've been part of acquiring a competitor where it was mandated to do it slowly and learn about them first,  so we kept them running "as is" and slowly integrated with our technology stack. In that instance, we had enough time to do discovery, had access to their systems and could plan the transition in stages, so the whole integration was driven by IT and on my team's terms. I was part of another acquisition where we moved/migrated them to our data center, but it was more of a lift and shift move, they continue to run as a separate system. A 3rd acquisition was a spin-off from the parent company and we had a month to migrate/integrate to our system as the parent company was cutting off AD/Exchange/Phone etc. There was a very little heads up there and the whole thing is driven by the CEO where IT is told to do something by a certain day so you need to improvise and make it work, you have little input on the date and need to do thorough analysis and migration plan on the fly. 
The point is every acquisition is different. I have been part of four and each is different than the other, systems are different, access is different and timelines and expectations vary. The next one will again likely be something different and unique.

Content you might like

Too many active projects at once43%

Poor communication46%

Too many customizations47%

Misalignment with business priorities34%

Skills gaps31%

Lack of resources26%

Other (please list in the comments)1%


757 views1 Upvote

CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.
Read More Comments
47k views133 Upvotes324 Comments

Discretionary budgeting8%

Strategic budgeting72%

A combination of discretionary & strategic budgeting17%

Other (please explain in the comments)1%


918 views1 Comment