How to Do Technology Due Diligence Before an Acquisition

A client called me two months after closing an acquisition. They'd bought a SaaS company for its customer base and product capabilities. The financial due diligence was thorough — audited financials, customer cohort analysis, revenue quality assessment. The technology due diligence was a one-day review by a generalist consultant who concluded "the technology stack is modern and appears well-maintained."

Three months post-close, they discovered: the entire deployment process depended on one engineer who was leaving at the end of his earn-out, the database couldn't handle the combined customer base without a significant migration, there were unpatched security vulnerabilities that the target's largest enterprise prospect had flagged during procurement, and 30% of the codebase was built on a library with a license that restricted commercial use in ways that conflicted with the acquirer's business model.

Total cost to remediate: $1.2M and 8 months — none of which was in the integration budget.

IP Ownership and Licensing

This is the one that bites hardest when missed. Three specific questions:

Does the company own its code? If the application was originally built by a contractor or agency, check the contract. Some development agreements retain IP rights for the development firm. If the company's engineers used open-source components (they did), verify that the licenses are compatible with commercial use and that attribution requirements are met.

Are there license encumbrances? Tools like FOSSA or Snyk can scan a codebase and flag every open-source dependency along with its license. GPL-licensed code in a proprietary application is a legal time bomb. AGPL-licensed server-side code can require you to open-source your entire application. Even permissive licenses like MIT and Apache have attribution requirements that companies often ignore.

What about third-party data? If the product uses third-party data (maps, business listings, financial data), verify that the data license transfers with the acquisition and supports the intended use at the post-acquisition scale.

Architecture Scalability

Don't ask "is the architecture good?" Ask "can the architecture support the business plan?"

If the acquisition thesis assumes 3x revenue growth over three years, the technology needs to support 3x the users, 3x the transactions, and 3x the data — at minimum. This isn't theoretical; it requires specific analysis.

Where are the database bottlenecks? What happens to response times at 3x current load? Can the infrastructure scale horizontally (add more servers) or does it require vertical scaling (bigger, more expensive servers)? Are there hardcoded limits — connection pools, queue sizes, rate limits — that would break at scale?

I run load tests as part of every technology due diligence engagement. Not to prove the system can handle theoretical traffic, but to identify where it breaks. The break points tell you what the post-acquisition technology investment needs to address.

Key-Person Risk

In acquisitions of smaller companies, the technology often lives in one or two people's heads. If those people leave — and in acquisitions, they frequently do after the earn-out period — you inherit a system that nobody understands.

Map every critical system to the people who can maintain it. If any critical system has a bus factor of one, that's either a retention priority (keep that person happy) or an immediate knowledge transfer priority (document and cross-train before the acquisition closes, not after).

Pay special attention to: deployment procedures (can anyone besides the CTO deploy?), infrastructure management (who has the AWS root credentials?), vendor relationships (who manages the contracts with critical third-party services?), and customer-specific configurations (are there special arrangements or custom integrations that only one person knows about?).

Security and Compliance

A security assessment during due diligence isn't optional — it's a liability assessment. Unpatched vulnerabilities, exposed credentials, and compliance gaps transfer to the acquirer.

The minimum viable security assessment checks: penetration test results (if they exist; if they don't, that's a finding), access controls (who has production access and is it managed properly?), data handling (is PII encrypted, is there a data retention policy, are there GDPR obligations?), incident history (have there been breaches or near-misses?), and compliance status (SOC 2, HIPAA, PCI DSS — whatever's relevant to the customer base).

Any security finding translates directly to cost: either the cost of remediation or the cost of a breach. Include these in the deal model.

Integration Complexity

The most overlooked dimension. Two companies' technology stacks need to work together post-acquisition. How hard is that?

Different authentication systems need to be unified. Different data models need to be reconciled. Different deployment pipelines need to be coordinated (or one needs to be migrated to the other). Different monitoring, logging, and alerting systems need to be consolidated.

I estimate integration complexity on a 1-5 scale for each dimension and use it to project integration timeline and cost. A fully compatible stack (same languages, same cloud provider, similar architecture) might integrate in 3 months. Completely different stacks might take 12-18 months. The deal model needs to account for this.