Table of Contents
This blog series also appeared as an article in the 11/2020 issue of the German M&A Review magazine. The specific issue of M&A Review can be found here.
The blog series addresses the following aspects of software due diligence:
In the following 1st part of the three-part series, we are going to discuss the first point about the particular valuation risks of software targets.
The rapidly advancing digital transformation is a technological challenge for many companies. Those who do not convert their company in time can quickly lose touch in their industry. In many industries, the definition of one’s own core competence must be reassessed from the perspective of the all-encompassing digitalization [1]. The technologically motivated acquisition of a tech target is often an option to accelerate one’s own digital transformation through an inorganic technology leap.
Statistics show that as much as 15% of M&A transactions today are carried out in connection with a digitalization strategy [2]. A classic example is the machine and plant manufacturer who takes over his software supplier. The aim is to further develop the margin-attractive and growing area of data-based (e.g. IoT) services as a new core competence. Data may be the new gold – but it is the software that turns cryptic data into commercially usable information in the first place.
Therefore, the core technology of the tech targets considered here is software. In addition to software companies that are already established, tech start-ups are often also interesting acquisition targets. What both have in common is that software assets involve a comparatively high investment risk because the product functionalities have a short life cycle and the sustainable value of the assets is not obvious. Without software specialists and special tools, it is impossible to recognize whether a software is still immature or already outdated, or whether it has been programmed only unprofessionally.
The considerations also apply analogously to companies with extensive software applications that were developed in-house. They represent an important factor in competitive differentiation and profitability, but are only used for internal use. The focus of the presentation is oriented towards the buy-side. Some notes for the sell-side are marked as such.
A software due diligence should not be mixed up with an IT due diligence or considered as part of it. The tools and skills required are completely different. In the following, the authors focus on Software Due Diligence and refer to [3] for the also useful IT Due Diligence. Tech targets with software as product or core technology are challenging acquisitions in terms of their valuation. Both the seller and the investor derive the valuation of these companies from future projections, which are often very optimistic in the case of start-ups. Rarely, however, are they based on reliable historical data with regard to market relevance, competitive advantage or sustainability of an innovative income model. An experienced investor can judge this information with regard to commercial, legal or tax risks after due diligence.
Only in exceptional cases, however, is the question adequately answered as to whether the life cycle of the software assets has already largely expired and these may not be able to be adapted much longer to new requirements with economically reasonable effort. The question also remains open as to whether the technological basis and development processes are sufficiently scalable or integrable for the ambitious investment hypotheses. It is also not answered whether there are risks in the distribution of know-how among the key developers or whether there are risks due to a lack of code documentation.
The development processes deserve special attention from the consultants, since digital transformation has fundamentally changed the demands on software development. It is no longer just a matter of optimizing or stabilizing. It is about developing a constantly well-filled pipeline of innovations efficiently and developing it quickly to market maturity. In a planned M&A transaction, these questions regarding the relevant quality, development and potential characteristics of a software and its development processes can only be answered by a software due diligence.
In addition, it should be noted that the software under analysis is further developed and modified in the period between due diligence and closing. Depending on the duration of contract negotiations, these changes (bug fixes, market requirements, R&D roadmap) can be quite substantial, but also important and useful. The authors recommend including a before-and-after comparison of the software assets in the contract. This ensures that the successful investor can validate whether new risks will not occur with the software that has been modified during the duration of the transaction. With the help of the initial deployment and a new run of the analysis software, it takes only a few days to deliver this important comparison.
A special challenge for the commercial success of software is the so-called technical debt. It arises, for example, in agile software development through the method-specific focus on the functionality of the software – at the end of each sprint (partial development), a product with new features must be available without explicitly allowing time for quality improvement. Developers who are already challenged by tight budgets, time pressure or unclear requirements make knowingly or unknowingly suboptimal decisions in order to meet the project objectives [4]. The result is a code base that is burdened with legacy issues (“code smells”) right from the start.
Technical debt is nevertheless unavoidable in any software. Addressing it also needs to be the focus of regular maintenance work. Too high technical debt, however, means that the effort for maintenance or for the implementation of new requirements and functionalities will increase over time.If a software is not built methodically, structured and quality-assured, new technical debt will arise with every change and every release. Sooner rather than later, this debt takes on a dimension that makes further development of the software uneconomical. The only alternative then is to develop the software anew from scratch. This conclusion could become a potential deal breaker for the investor. The goal of software due diligence is to assess the level of technical debt, identify the problematic areas in the code and categorize the effort required to fix it as critical or non-critical.
Note for sell-side: It makes sense in the preparation of the company/a department for a M&A transaction to know its technical debt in detail through a Software Vendor Due Diligence. This gives the opportunity to eliminate the largest defects in the software in advance of the selling process. This could reduce unnecessary conflicts in the negotiations and could improve the achievable price.
Let me complete with some of the important questions that should be asked about technical debt as part of a software due diligence:
Part 2 of the three-part series looks at the areas of investigation in software due diligence and why a mix of tools and experience is needed.
Have you ever dealt with software assets in an M&A transaction? Was it successful? What were the challenges in your case? Don’t hesitate to share your thoughts with us.