Lessons Learned From 50 Technical Due Diligence Reviews For Acquirers

Previously published on Forbes on August 12, 2022

Management teams seem to forget a critical rule when acquiring another company: The original product road maps of both acquiring and acquired companies must be delayed by at least one quarter. The reason is simple: Resources from both acquiring and acquired teams need to dedicate this time to merging the technology stacks, tools and processes of the two companies.

In a prior article, I covered the technical review needed prior to an investment. An acquisition requires additional work, which I’ll cover here.

The benefits of buying a company are easy to get excited about: New market segment, new customers to which to upsell the current product, new technology, etc. Yet, the effort and time needed to realize these benefits are often overlooked. Whether because of time pressures or over-exuberance, the acquiring management team often glosses over the intricacies of integration, oversimplifying the work needed, which results in a vastly underestimated budget, human resources and time.

In the worst case, the impact goes beyond delaying the benefits of the acquisition—because existing resources must be reallocated to the integration of the acquired company, the acquiring company’s original product road map itself is delayed, resulting in lower revenues. By engaging in thorough technical due diligence (tech DD) the acquiring management team can avoid these pitfalls.

Tech DD will force answers to tough questions on the future operation of the combined entities:

• Will the two products run side-by-side (simpler initially but likely costlier to operate), or will they merge into a single platform (challenging initial integration efforts and generating multiple long-term benefits)?

• What is the long-term technology stack—and how much effort will it take to get there? Even with similar technology stacks, framework versions have to be aligned, along with templates, design patterns, log aggregation, performance monitoring, etc. Tool stacks must be evaluated: code repository, CI/CD toolchain, identity framework, test automation, application monitoring and alerting, security, etc. There are often dozens of such evaluations to make.

• For each tool or framework that differs between the two companies, an analysis of “merge” versus “siloed” must be made comparing the upfront costs of merging versus the long-term savings. The absence of automated tests often increases the effort and risk of merging, whether it entails refactoring code or changing tools.

• On the other hand, keeping siloed not only duplicates costs but reduces knowledge sharing and increases the overall complexity in releasing features, as well as managing a more fractured team.

• On the operations side, migrating data centers is no easy task. The more a product leverages the services offered by a cloud provider, the more complex the migration is, whether it is for databases, container orchestration or management consoles.

• Unifying data is another challenge: Something as apparently simple as standardizing the attributes and representation of core entities in the system (e.g., a user) demands lengthy detailed analysis and code refactoring.

• Who will execute the technical integration? At least initially, the most valuable members of both teams are needed to make the critical evaluations. As a corollary, what projects will be neglected, and which new features will be delayed? How does this impact customers and projected revenues?

• Alternatively, outside contractors can be brought on to handle the temporary surge of work caused by the integration. In practice, because of the overhead of onboarding contractors, this approach works best if working with an existing partner—or one that the company intends to work with for the long term.

• How quickly, and through what processes, must the acquired company rise to the security and compliance requirements to those of the acquiring (larger) company?

• Were expectations properly managed? In the euphoria of the deal, double-dipping often happens. The sales team expects that the two companies’ road maps will be delivered unaltered, while the financial team expects cost savings from the two companies’ synergies. In addition, the integration budget is often severely underestimated.

As an illustration, imagine a company running on AWS with a tech stack based on Node.js and RDS/PostgreSQL acquiring a company running on Azure with a .NET tech stack. What is the cost/benefit of running the two products “as is” on separate software infrastructure, versus migrating to AWS and/or Node.js? An alternative might be to acquire a competitor of the target company that runs natively on an AWS/Node tech stack, if one exists, even if its business position is not as strong. A simpler integration will accelerate the time-to-market for the combined company, making up for the initial comparative disadvantage.

In short, the amount paid to transfer ownership of the acquired company may only be a fraction of the total cost of the acquisition. Other costs stem from additional resources, financial and human, needed for the integration and from revenue offsets from delays due to integration.

At a minimum, tech DD for an acquisition will present a more realistic view of the total cost of acquisition. While tech DD will only outline the myriad “merge” versus “siloed” technical decisions that will eventually need to be made, this will force a critical examination of the integration road map, along with refined estimates of the effort and time required. With this information, the management team can de-risk the decision to acquire, build post-deal milestones and accelerate the time-to-market of the combined products.

Leave a Reply

%d bloggers like this: