Financial and legal due diligence are routine. Technology due diligence is frequently skipped on smaller transactions, and it is where a specific set of liabilities lives — ones that do not appear in accounts and are not covered by standard warranties.
Ownership: does the business own what it uses?
The first question, and it produces findings more often than any other.
The domain. Registered to the company, or to a director personally, or to a former web developer? A domain outside the company is not included in an asset sale and may not transfer.
The website and any custom software. Is there a written assignment of copyright? Without one, commissioned work may remain with the creator. A business selling a bespoke system it does not own is a real problem.
Hosting and accounts. In the company's name, or in an employee's personal account? Analytics, payment providers, cloud services, certificates. Each in a personal account is an item that must be transferred, and may not be.
Software licences. Licensed to the company, in sufficient quantity, and transferable on a change of control. Licences bought on personal cards and expensed are common in smaller businesses and are frequently non-transferable.
The general shape of the problem is in who actually owns your website.
Key person risk
The most commonly underestimated finding in smaller acquisitions.
Ask: who understands each system? If the answer is one person for anything material, that is a risk to price into the deal — particularly if that person is a departing owner or somebody whose loyalty is to them.
Look for: undocumented custom software, automation nobody can explain, spreadsheets doing operational work, and administrative access held by one individual.
The mitigation is usually a transition arrangement with the individual, agreed before completion rather than negotiated after — see automation that survives its author.
Contracts and change of control
Read the supplier agreements for termination and change-of-control provisions.
Things that catch acquirers: contracts that terminate or require consent on a change of control; long remaining terms with no exit; licences priced per entity that reprice on transfer; and support arrangements tied to the outgoing owner personally.
Also check exit terms generally. A business dependent on a supplier it cannot leave carries that dependency into your ownership — see avoiding vendor lock-in.
Data
What personal data does the business hold, on what lawful basis, and for how long?
You are acquiring the obligations along with the records. A target with no retention policy, no record of consent, and customer data going back fifteen years is inheriting you a problem.
Ask directly whether there has been a breach, whether it was reported, and what was done. This is a question worth asking explicitly rather than hoping a warranty covers it.
Also assess data quality, because it determines how expensive integration will be. A customer database with heavy duplication is a migration project rather than an import.
Infrastructure and security
What is running, and is it supported?
Unsupported operating systems, hardware past its life, unpatched systems and expired certificates are each a cost you will bear shortly after completion. Quantify them.
Check the basics: is multi-factor authentication in place; are backups running and have they been restored; who has administrative access, including former staff and suppliers; and is there anything exposed to the internet that should not be.
Former employees retaining access is a common finding and a straightforward one to check.
Most technology findings in a small acquisition are not dramatic. They are a list of things that must be paid for shortly after completion, and pricing them is the point.
Integration cost
If the target's systems must merge with yours, that is a project with a cost that belongs in the model.
What determines it: whether the systems are the same or different, how clean the data is, how many custom integrations exist, and whether either side has undocumented processes.
Be realistic. System integration after an acquisition consistently takes longer than planned, and the usual cause is data quality nobody assessed.
The questions that produce the most
- What would happen if [key individual] left the day after completion?
- Show me the list of every system in use, including the ones on personal subscriptions.
- Who currently has administrative access to each?
- When was a backup last restored, and by whom?
- Has there been a security incident, and what happened?
- Which contracts have change-of-control provisions?
- What is registered or licensed to an individual rather than the company?
Ask them of the people running the systems as well as the directors. The answers frequently differ, and the difference is itself informative.
Proportionate effort
For a business where technology is incidental, this is a day's work. For one where the systems are the business, it warrants considerably more.
Either way it is small relative to the transaction, and it regularly finds items that affect price or terms rather than merely the integration plan.
Our consultancy team carries out technology due diligence for UK acquisitions, with findings written for the deal team rather than for engineers. Start a conversation.
