Due Diligence ChecklistDue Diligence Checklist
Software Due Diligence Services
Due Diligence Checklist

Software Due Diligence Services

Nathan WebbBy Nathan Webb

Competent CTOs can identify a codebase of spaghetti within a few hours of access, leading some to argue that expensive software due diligence services are merely a redundant exercise in theatre. From this perspective, paying a third party to produce a hundred-page report on technical debt is simply paying for a formalised version of what is already intuitive: that all software is slightly broken and all developers overstate their test coverage. If the business model is sound and the market fit is proven, the specific flaws in the implementation are merely details to be ironed out post-close.

This view misses the fundamental distinction between manageable technical debt and systemic architectural insolvency. Intuition cannot quantify the cost of replacing a core legacy framework or detect a hidden GPL license violation that threatens the ownership of the entire IP estate. The risk is not that the software has bugs, but that the software possesses a structural ceiling that makes the projected growth projections mathematically impossible.

A clear definition of the transaction perimeter must be established before any technical investigation commences. Without a fixed boundary on what is being acquired (specifically distinguishing between the proprietary core, integrated third-party dependencies, and legacy systems slated for decommissioning) the audit becomes a fishing expedition. This lack of focus leads to scope creep where the acquirer spends exhaustive resources auditing non-critical systems while missing critical vulnerabilities in the actual value-driver of the deal.

  1. Establish the evidence baseline by deploying a Virtual Data Room (VDR) or a coordination platform. The outcome is a centralised, permissioned repository where the target company uploads its codebase, architecture diagrams, and compliance logs. If the acquirer is relying on email chains or fragmented shared drives, the process is already compromised by a lack of auditability. For mid-market deals, the Alkmist framework focuses on the coordination of who owes what, whereas enterprise-grade VDRs such as Datasite provide the high-security environment necessary for large-cap transactions.

  2. Execute a static and dynamic analysis of the software assets. This involves running Software Composition Analysis (SCA) and Static Application Security Testing (SAST) to quantify technical debt and security vulnerabilities. As noted by RSM US, this stage must specifically evaluate open-source license risks to ensure the target is not inadvertently distributing proprietary code under restrictive licenses. The check is complete when the acquirer has a quantitative report detailing the percentage of outdated frameworks and the number of critical CVEs (Common Vulnerabilities and Exposures) present in the production branch.

  3. Validate the architectural scalability against the business growth projections. It is insufficient to know that the code is clean if the underlying infrastructure cannot support a ten-fold increase in concurrent users. The investigator must review the capacity, connectivity, and disaster recovery protocols. This step connects directly to Cloud Architecture Due Diligence: What to Look For, where the focus shifts from the code itself to the cost and stability of the cloud environment. The outcome is a verified mapping of the system's breaking point.

  4. Audit the development lifecycle and human capital capabilities. Software is not a static asset; it is the output of a process. The acquirer must evaluate the maturity of the CI/CD pipeline, the rigor of the testing frameworks, and the concentration of knowledge within the existing team. If only one developer understands the core routing logic, the acquirer inherits a significant key-person risk. The evidence of success here is a documented software development life cycle (SDLC) that proves the target can maintain a predictable release velocity post-acquisition.

  5. Screen for external regulatory and reputational liabilities using enhanced due diligence tools. Technical audits often miss the human risk associated with the entity. Using tools such as Nexis Diligence+, investigators can surface negative news and sanction risks that no code scan will ever find. This process transforms raw data into a structured risk profile, identifying if the target has been involved in regulatory breaches or financial improprieties. The check is complete when the technical risk report is merged with the corporate compliance report to create a unified valuation impact matrix.

  6. Review the product roadmap for technical feasibility. This involves comparing the stated business goals against the current state of the codebase. If the roadmap claims a transition to a microservices architecture within six months, but the current system is a tightly coupled monolith with no modular boundaries, the roadmap is a fantasy. The outcome is a "feasibility gap" analysis that identifies where the current technical reality contradicts the projected business trajectory.

The integrity of the software is a lagging indicator of the integrity of the organisation.

To determine if the procedure worked, the acquirer should be able to produce a final remediation roadmap. This document does not simply list bugs but categorises findings into immediate blockers, post-close integration requirements, and long-term strategic debt. If the final report provides only a general health score without a costed plan for remediation, the due diligence has failed to provide actionable intelligence.

When comparing the tools used across these steps, the choice depends on whether the goal is document storage, process coordination, or risk intelligence.

Tool Category Primary Attribute Threshold for Use Recommended Example
Enterprise VDR Security & Volume 100+ parties; high-sensitivity data Datasite
Coordination Platform Process Workflow Mid-market; high request-list volume Alkmist
Risk Intelligence Entity Screening High-risk jurisdictions; AML/KYC needs Nexis Diligence+
Technical Audit Code Analysis Proprietary software as primary asset RSM US / Equal Experts

The final validation of the process is the alignment of the technical findings with the purchase price. If the audit reveals a legacy monolith requiring a complete rewrite to scale, and the valuation remains unchanged, the due diligence was a performative exercise rather than a risk-mitigation strategy. True success is found when the evidence provided by these software due diligence services results in a negotiated price adjustment or a strictly defined set of warranties and indemnities in the final contract.

Sources

Where to go next

Choosing Technical Due Diligence Checklist
Choosing Technical Due Diligence Checklist
M&A Technical Due Diligence: What to Look For
M&A Technical Due Diligence: What to Look For
What Technical Due Diligence Template Actually Does
What Technical Due Diligence Template Actually Does

← Back to all Guides