A company may have growing revenues, a stable customer base and a compelling product, whilst at the same time harbouring a technological bill that only becomes apparent following a change of ownership.
This risk is becoming increasingly significant as the M&A market recovers. PwC estimates that the value of global transactions could reach $4 trillion in 2026, around 13 per cent more than the previous year. At the same time, the number of transactions is set to fall by a similar margin. Capital is therefore concentrating on larger assets, and the pressure to get valuations right is mounting. This is particularly true in the software sector, where AI is transforming business models, barriers to entry and the assessment of future competitive advantage.
In such transactions, technology is no longer merely a technical add-on to due diligence. It can alter the value of an asset, the economics of integration and the timeframe for achieving the anticipated synergies.
Technology debt is factored into the valuation too late
This is clearly illustrated by a KPMG survey of 135 specialists involved in technology transactions. Only 27 per cent of respondents considered addressing the issue of technology debt to be a high priority when assessing a company prior to a transaction. At the integration planning stage, this figure rose to 68 per cent, and stood at 67 per cent following the acquisition.
The problem does not, therefore, arise after the contract is signed. That is when it starts to cost money.
Technology debt can mean a monolithic architecture that is difficult to scale, an outdated tech stack, insufficient testing, manual deployments, poor documentation, or a product that depends on a handful of people who understand its key components. The system may efficiently support current business operations, but it may not be able to cope with a doubling of traffic, expansion into a new market or integration with the buyer’s platform.
EY identifies scalability, architecture, technical debt, hosting costs and the R&D team’s ability to execute the roadmap as areas that can directly undermine investment assumptions in software transactions. Integration issues often only come to light when it is necessary to merge two environments, standardise products or implement a shared infrastructure.
The code may have a different value than that suggested by the presentation
A separate issue is what actually lies within the code of the acquired company. Modern software is built from thousands of dependencies, libraries and components developed outside the organisation.
In 2026,Black Duck analysed 947 commercial code bases. Open source was present in 98 per cent of them, at least one vulnerability was detected in 87 per cent, and licence conflicts were found in 68 per cent. The figures relating to M&A deals themselves are even more striking: open source was present in all the transactions analysed, 94 per cent involved code with licensing conflicts, and 97 per cent contained unpatched vulnerabilities.
This is not solely a matter of cybersecurity. A licence may restrict how a product is distributed, force the disclosure of part of the code, or lead to a dispute over intellectual property. Similar risks arise with code created by freelancers, software houses and, increasingly, generative AI tools.
The value of ‘in-house technology’ may therefore appear different once its origin has been verified.
Cybersecurity risks may be inherited along with the company
The buyer acquires not only the servers and applications, but also their history: inactive administrator accounts, faulty cloud configurations, unpatched systems, API keys, third-party providers and potential traces of previous breaches.
Deloitte highlights the period immediately following an acquisition as particularly dangerous. Changes to permissions, network integration and the reorganisation of security policies create temporary vulnerabilities, whilst the very fact of the transaction itself may attract increased interest from attackers.
In practice, the poor security of the acquired company may necessitate immediate investment before its systems can be securely integrated into the group’s infrastructure.
The cloud may mask a profit margin problem
In the case of SaaS, one of the most underestimated factors is the economics of the infrastructure. Rising revenue does not necessarily mean rising profitability if the costs of computing, data storage or external APIs increase almost linearly with product usage.
Therefore, the mere fact that a company operates‘in thecloud’ says very little. What matters is the architecture, resource utilisation, dependence on a specific provider, the ability to migrate, and the relationship between hosting costs and revenue growth. EY already treats this analysis as one of the standard elements of technological due diligence for software companies.
Added to this is AI. From 2 August 2026, the European Commission and national authorities began enforcing the next phase of the AI Act, including new transparency obligations. In companies developing AI-based products, training data, the origin of models, dependence on external suppliers and the ability to meet regulatory requirements are therefore also becoming the subject of transactions.
Technological due diligence is becoming less and less about checking whether a product works. It is far more important to determine whether its architecture, code, data and team are capable of delivering the growth factored into the valuation.
The most costly technological issues do not usually prevent a sale from going ahead. They begin to erode the company’s value after the deal has been closed.
