Technology due diligence

In each area we answer the same questions: what is there, who owns it, what happens when it stops working, and how much work it takes to put it in order.

Systems. We list the systems that run sales, customer service, billing and production: where they run and who has administrative access, meaning the right to change settings and users. We establish which ones the company bought, which it built itself and which run with a supplier whose contract may expire with the change of owner.

Code. Source code is the record of how a program works, which a developer reads and changes. We check whether it sits in a repository, a place that keeps every version with a history of changes, and whether another person could build a working system from it without the authors' help. We also assess technical debt: shortcuts in building the system that someone will have to pay back with work.

Data. We establish where data on customers, contracts and transactions sits, who owns it under the contracts and whether it can be taken out of the system. We check backups: whether they are made and whether anyone has ever restored the system from them, because a backup that has never been restored is only an assumption. With personal data we check whether the company knows where it got it from.

Licence agreements. A licence is the set of terms on which the company uses someone else's software. We check commercial licences for change of ownership: some require the vendor's consent or change the price when the company passes into other hands. We check open-source software, code available free of charge on its author's terms, because some of those terms may require the company to disclose its own code. The legal assessment is issued by a law firm; we provide it with a list of contracts and places in the code to check.

IT team. We check how much knowledge of the systems exists only in the heads of the people who maintain them. We establish who is an employee, who is a subcontractor and whether the contracts transfer to the company the rights to the code these people wrote. We describe dependence on a single person in the report without names.

The result is a report for the board: the state of each area, risks by weight and an estimate of the work needed to remove them. A review of your own systems with no transaction behind it is a separate scope, as is a plan for connecting the two companies' systems after the purchase.

1. We agree the scope and access. With you and the transaction advisers we establish what is being bought and the order of checks; with the seller we agree documents, access and people to interview under a non-disclosure agreement. Outcome: a review plan and a list of what the seller makes available.
2. We read documents, code and system settings. We work on the seller's materials and servers, without copying data. Outcome: a description of the state of each area and a list of questions the documents do not answer.
3. We talk to the seller's IT team. The people who maintain the systems show us how they make a change, handle an outage and restore a system from a backup. Outcome: findings confirmed or corrected, and an assessment of dependence on individual people.
4. We hand over the report. We discuss it with you and the transaction advisers: which risks to negotiate, which require a decision before signing. Outcome: a report with a risk register and an estimate of the cost of putting things in order.