Technical debt is one of those terms that means different things to different people. In M&A due diligence, it needs to mean one specific thing: the cost to remediate known technical deficiencies, expressed in dollars and time, before the acquired company’s technology infrastructure can be considered adequately maintained.
This is not an academic exercise. Technical debt in M&A shows up as integration delays, budget overruns, and — in the worst cases — security breaches that exploit vulnerabilities the acquirer didn’t know existed.
The Four Types of Technical Debt in M&A
Type 1: Code Quality Debt
The target built internal applications. Those applications are running on frameworks, languages, and libraries that are now end-of-life or approaching it. The cost to remediate: rewrite or upgrade.
Indicators in due diligence:
- Internal applications running on .NET Framework 4.8 or below (end-of-life announcement pending)
- Java applications on Java 8 or below (Java 8 EOL April 2026)
- Node.js applications on versions below 18 (LTS)
- Python 2 applications still in production
- Open-source libraries with known critical vulnerabilities (log4shell, Spring4Shell, and similar)
Quantification method: Estimate lines of code per application, apply industry standard rewrite cost ($40-80 per line of code for enterprise applications), add 30% for testing and deployment. A 50,000-line Java 8 application = approximately $2.6M-$5.2M to rewrite or upgrade.
Type 2: Infrastructure Debt
The target’s on-premises infrastructure is aging. Servers are approaching end-of-support. Network equipment is underpowered. Storage is running low. The cost to remediate: refresh.
Indicators in due diligence:
- Windows Server 2012 or 2012 R2 (EOL October 2023)
- SQL Server 2012 or 2014 (EOLJuly 2024 for SQL 2012)
- VMware vSphere 6.x (EOL mainstream support passed)
- Any server hardware more than 5 years old (failure rate increases significantly after 5 years)
- Network equipment beyond end-of-sale date from vendor
Quantification method: Count servers by OS version and age. Get hardware refresh quotes from Dell, HPE, or a VAR. Add 20% for installation, migration, and testing labor. Infrastructure debt for a 100-server environment with significant 2012-era hardware typically runs $800K-$1.5M.
Type 3: Security Debt
The target’s security posture has gaps. These are known vulnerabilities that haven’t been remediated — often because the security team didn’t have the budget or the IT team didn’t prioritize them.
Indicators in due diligence: Patch levels on endpoints, EDR coverage gaps, MFA adoption rate, privileged account count, legacy protocol usage (NTLM v1, LDAP simple bind), unpatched vulnerabilities in externally facing systems, expired SSL certificates on production systems.
Quantification method: Use ACQI’s security posture module to produce a security debt score. Compare against industry benchmark (Censinet or BitSight scoring). Estimate remediation cost per finding at $5K-$50K for enterprise environments, depending on complexity. A typical mid-size company’s security debt for findings rated High or Critical runs $200K-$800K.
Type 4: Technical Support Debt
The target’s IT team is firefighting. They’ve been solving problems reactively for so long that they haven’t had time to document anything, automate anything, or build the infrastructure that would make the environment sustainable.
Indicators: No runbooks. No configuration management database (CMDB). No change management process. Network diagrams that don’t match reality. Passwords stored in spreadsheets. No backup documentation. No disaster recovery plan tested in the last 12 months.
Quantification: This is the hardest debt to quantify because it’s organizational, not technical. The remediation is process documentation, knowledge transfer, and hiring or training. For a 500-person IT organization, this typically runs $300K-$600K over 18 months.
The Technical Debt TCO Model
Combine the four types into a single model. For a mid-size acquisition target with moderate technical debt:
| Debt Type | Estimated Cost | Remediation Timeline |
|---|---|---|
| Code Quality | $1.5M-$4M | 12-24 months |
| Infrastructure | $800K-$1.5M | 6-12 months |
| Security | $200K-$800K | 3-12 months |
| Support Process | $300K-$600K | 6-18 months |
| Total | $2.8M-$6.9M | 12-36 months |
This number needs to go into the deal model. It’s the cost of making the acquired company’s IT environment as good as it should have been — and it should have been better.
The Integration Velocity Tax
Technical debt has a second-order cost that doesn’t show up in the TCO model: it slows integration velocity.
Every sprint that the integration team spends firefighting infrastructure problems or remediating security findings is a sprint that isn’t spent on the actual integration work — migrating users, consolidating platforms, capturing synergies.
At a PE firm doing 2-3 acquisitions per year, integration velocity is a competitive advantage. Companies that can integrate faster capture synergies faster. Technical debt is a tax on integration velocity.
What You Do With This Number
The technical debt assessment should result in a number that goes into the deal model — either as an adjustment to the purchase price, an escrow holdback, or a specific indemnification from the seller for known technical debt items.
The key is to make it specific. “Technical debt” as a line item in a deal model means nothing. “Windows Server 2012 infrastructure refresh: $420K. SQL Server 2012 upgrade: $280K. Security findings remediation: $340K. Total: $1.04M” — that’s a line item that a seller can actually negotiate around.