Four weeks, properly scoped, usually finds between one and three things that move the price. Here is what to look for and in what order.
In mid-market acquisitions, technology diligence is frequently the last workstream commissioned and the first one compressed. Financial and legal diligence have fixed, well-understood processes. Technology gets a week, a document request, and an interview with whoever is nominated.
That is usually enough to confirm that systems exist. It is not enough to find the three categories of problem that actually matter, and those three categories are worth considerably more than the fee.
What you are actually looking for
Not "is their IT good". Their IT is a mid-market company's IT; it will be fine in parts and held together in others, like yours. You are looking for three specific things.
Liabilities you would inherit. Unlicensed software, a breach that has not been disclosed, contracts with change-of-control clauses that trigger on completion, data held in ways that create regulatory exposure.
Costs that are not in the model. Hardware at the end of its life, systems past vendor support, a platform migration that has been deferred three times, licensing that has been under-counted.
Fragility that survives the deal. The system one person understands, the backup nobody has restored, the vendor dependency with no exit.
Everything else is interesting and does not change the price.
Four weeks is enough
The structure above assumes you can talk to people. If diligence is being run confidentially and you cannot, the quality drops sharply and you should say so explicitly in the findings rather than pretend otherwise. A document-only review finds documented problems, and documented problems are rarely the expensive ones.
The document request, kept short
Long document requests produce incomplete responses and annoyed sellers. A short, specific one gets answered. Ask for:
An asset list with purchase dates. The licence position for the major platforms, with seat counts. A list of all software vendors with annual cost and renewal date. Network and system diagrams, however out of date. The last penetration test or security assessment and the remediation status. Any incident in the last three years. The backup configuration and the date of the last restore test. Contracts for the five largest technology vendors. Names and roles of everyone who touches IT, including contractors.
That list fits on one page and asks for things that exist. The last item does more work than the rest combined.
What to look for, by category
Ownership, which is the one that voids deals
Does the company own its own domain names, and is the registrant the company rather than a former contractor's personal account? Does it own the code it depends on, with written IP assignment from every contractor who wrote any of it? Who holds the top-level administrative credentials for the cloud tenants, and is that a person who is leaving at completion?
These sound like edge cases. They are not. A domain registered to the founder's personal email, or a core application written by a contractor with no assignment agreement, is a real and recurring finding, and it has to be fixed as a condition rather than discovered afterwards.
Licensing
Count the seats. Compare with the headcount. This single check finds a material discrepancy often enough to be worth doing first, in both directions: the company paying for ninety licences and using sixty is an immediate saving, and the one using ninety and paying for sixty is a liability with a vendor audit attached.
Also check for per-core or per-socket licensing on anything virtualised, which is where the most expensive surprises live.
Fragility
Ask each technical person the same question: "What would break if you were unavailable for a month?" People answer this honestly, because it is not a question about their performance. The union of the answers is your key-person risk map, and it is more accurate than anything in the data room.
Then ask when the last full restore was performed and how long it took. A plan is not an answer.
The integration cost nobody models
If the acquisition is going to be integrated rather than run standalone, there is a cost that is almost never in the financial model and is reliably six figures for a mid-market deal.
Two identity systems have to become one, or be federated. Two email platforms. Two networks, possibly overlapping address space. Two sets of security policies, where one of them is weaker and is now attached to your network. Device fleets with different management tooling and different standards.
A reasonable rule of thumb for a first pass: assume twelve to eighteen months for full identity and platform integration, and budget for the external help, the licence overlap during the transition, and the device refresh that integration forces. Then ask whether running it standalone for two years is cheaper, because it often is.
Writing it up
The report that gets used has three parts and the first one fits on a page.
Findings that affect the deal, each with an estimated cost and a recommendation: price adjustment, condition precedent, warranty, or walk away. Usually one to three items.
Costs for the first two years, as a table. Not a risk register: a number the deal team can put in the model.
The hundred-day plan, meaning what has to happen immediately after completion. Usually credential transfer, closing the leavers, and whatever the first finding was.
A thirty-page assessment of their IT maturity is not what was bought. The deal team needs to know what it costs, what it risks, and what to do in the first week.
If the budget only stretches to one day
Check domain and tenant ownership. Count licences against headcount. Ask the three technical people what breaks if they are gone. Ask when the last restore happened.
Four checks, one day, and they find more deal-relevant risk than a fortnight spent reading documentation.
