The software due diligence checklist for acquirers is the structured set of requests and tests that turns a target software estate from an assumed cost line into a quantified position before close. A good checklist does two things at once. It makes sure nothing material is missed under time pressure, and it sequences the work so the highest risk areas are sized first. This is the working companion to the broader software due diligence method.
The checklist below is organised by area rather than by publisher, because the same disciplines apply across Oracle, SAP, Microsoft, IBM and the rest. For how to obtain the underlying data, see how to request software data from a target.
The software due diligence checklist for acquirers
Work the checklist in order of exposure, not order of convenience. The single most important test is deployment against entitlement, because that is where the gap and the number live. Everything else either feeds that comparison or interprets it.
Why a checklist beats an ad hoc review
A software estate is large, varied and easy to read selectively, so a review run from memory will always miss something. The value of a written checklist is that it forces coverage. It makes the team confront every high risk publisher, every licensing metric and every contract clause, rather than stopping at the ones that happened to surface in the data room. Under deal pressure that discipline is what separates a position an investment committee can rely on from a reassuring impression that collapses on first audit. A checklist also creates an audit trail of what was tested, which protects the buyer if a question is raised later about why an exposure was or was not priced. The structure is not bureaucracy. It is the mechanism that makes a time boxed review complete rather than merely busy.
Start with the data request
The checklist begins with a precise data request, because vague requests return vague answers. Ask for order forms, license keys and purchase history to establish entitlement, and for server, processor, user directory and SaaS administration data to establish deployment. Ask for the contract register so the licensing terms can be read against the deal structure. A target that cannot produce this data is itself a finding, because it signals an estate that has never been measured.
Cover the publishers that drive audit risk
Do not spread effort evenly. Concentrate on the publishers that produce the largest settlements: Oracle, SAP, Microsoft and IBM, with Broadcom now significant through VMware. As of mid 2025, SAP pursued AB InBev for a reported 600 million dollars and Diageo for a reported 60 million in disputes tied to indirect and inherited licensing, a reminder that a single publisher can carry the whole exposure. The discipline of prioritising publishers in a time boxed diligence is what makes a checklist work under deadline.
Key takeaways
- A good checklist prevents omissions under time pressure and sequences the highest risk areas first.
- The single most important test is deployment against entitlement, where the gap and the number live.
- Begin with a precise data request. A target that cannot produce the data is itself a finding.
- Concentrate on Oracle, SAP, Microsoft, IBM and VMware rather than spreading effort evenly.
- End with low, expected and high exposure ranges and a recommended lever per finding.
Read the contracts for the clauses that bite
Licensing terms decide what the exposure means in a deal. The checklist must capture anti assignment, change of control, audit and territory clauses, because these determine whether a transaction triggers consent, repricing or termination, and whether the structure helps or hurts. This is the commercial reading of the contract, distinct from the legal interpretation your counsel provides. The detail is in reading a target software contracts in due diligence.
Do not stop at perpetual licensing
The checklist has to cover SaaS and open source as well as on premises licensing. SaaS hides overspend in unused seats and auto renewing contracts, and it carries its own usage based exposure. Open source carries obligations that can attach to a target products. Both are easy to skip and both can be material. The red flags that should escalate any of these areas are listed in the 10 red flags in a target software estate.
Common mistakes in working the checklist
The checklist fails in predictable ways. The most common mistake is accepting the maintenance invoice as proof of compliance, when it only proves what the target chose to pay, not what it actually deploys. The second is measuring entitlement from the latest renewal alone, ignoring the upgrade, migration and inherited history that a publisher will hold the target to in an audit. The third is treating SaaS as low risk because it is subscription based, when unused seats and usage based exposure can be just as material as an on premises gap. The fourth is reading contracts for legal validity rather than for the commercial clauses that bite in a transaction. A disciplined checklist guards against each of these by measuring the estate itself and reading the contracts commercially.
How the checklist adapts to the estate
The same checklist applies to every deal, but the weight shifts with the estate. A SaaS heavy target moves the emphasis onto active versus paid seats, auto renewals and usage exposure, covered in software due diligence for SaaS heavy targets. A large on premises estate moves it onto cores, named users, options and indirect access. A carve out adds shared agreements and separation consent to the list. The checklist is a frame, not a script: it guarantees coverage while leaving the advisor to apply depth where the estate concentrates risk.
Recommendations for buyers
- Issue a precise data request covering entitlement, deployment, contracts and SaaS before fieldwork begins.
- Size every high risk publisher rather than accepting a representation that the estate is compliant.
- Capture anti assignment, change of control, audit and territory clauses and test them against the deal structure.
- Close the checklist with quantified exposure ranges and a recommended lever the deal team can use before signing.
A completed checklist feeds straight into the deliverable described in the software due diligence report, and the whole workstream is delivered through our software due diligence service.