In every acquisition, there are two balance sheets. The financial one gets scrutinized by accountants, lawyers, and advisors over months. The technical one — the state of the software that often is the product — frequently gets a cursory glance from an engineer who has two days and no structured methodology.
This is how acquirers end up owning systems with six-figure remediation costs that nobody budgeted for.
Technical debt is not a metaphor during M&A. It is a line item. Every unpatched CVE, every undocumented integration, every module that only one person understands — these translate directly into cost, risk, and timeline once the deal closes. The question is whether you discover them before the price is set or after.
What technical due diligence actually covers
A rigorous technical assessment examines five areas. Each produces findings that map to financial impact.
1. Architecture and scalability
What you're looking for: Can this system support the acquirer's growth plans, or will it need to be rebuilt?
- Monolith vs. services architecture. A monolith isn't inherently bad, but it constrains how quickly you can scale individual components. If the business plan assumes 10× growth, the system needs to support it.
- Database design. Normalized schemas scale differently than denormalized ones. A single-database design that mixes user data, analytics, and billing in one PostgreSQL instance may not survive a significant traffic increase.
- Infrastructure. Is the system running on a single server? Auto-scaling group? Kubernetes? The gap between "running" and "running reliably at scale" is often a six-month engineering effort.
Financial impact: Architecture limitations that require a rewrite or major refactoring post-acquisition typically cost €100k–€500k in engineering time. If discovered after the deal, this comes out of the integration budget.
2. Security posture
What you're looking for: Will this system pass a compliance audit, or will it trigger one?
- Dependency CVEs. Run automated scans against every package in the dependency tree. Legacy systems commonly have dozens of known vulnerabilities — some critical.
- Authentication and authorization. How are passwords hashed? How are sessions managed? Is there rate limiting? Are there any broken access control patterns?
- Secrets management. Are API keys, database credentials, and encryption keys stored securely? Or are they committed to the git history, hardcoded in source files, or shared via Slack?
- Compliance readiness. If the target serves financial data, health data, or EU personal data, are they GDPR-compliant? SOC 2 ready? PCI DSS certified?
Financial impact: A security incident in the first year post-acquisition is a brand and legal liability for the acquirer. Remediation of critical security findings typically costs €20k–€80k. Non-compliance with regulations can cost significantly more.
3. Code quality and maintainability
What you're looking for: Can the acquirer's engineers work in this codebase productively, or will they need months of onboarding?
- Complexity metrics. Cyclomatic complexity, code duplication, module coupling. High numbers in any of these predict high defect rates and slow development velocity.
- Test coverage. Not just the percentage — the quality. Do tests cover business-critical paths? Can you run them in CI? Do they pass consistently?
- Documentation. Architecture decision records, API documentation, deployment runbooks. If these don't exist, every piece of institutional knowledge walks out the door when employees leave post-acquisition.
- Dead code. Unused functions, commented-out blocks, entire files that are never imported. Dead code isn't just clutter — it's evidence of a codebase that hasn't been maintained.
Financial impact: Low code quality directly impacts developer productivity. A codebase with high complexity and no tests will slow down feature development by 30–50% compared to a well-maintained one. Over a year with a 5-person team at €100k/developer, that's €150k–€250k in lost productivity.
4. Team and knowledge concentration
What you're looking for: Is there a bus factor problem? What happens when key people leave?
- Bus factor. How many people understand each critical system? If the answer is "one," that's a single point of failure that becomes critical during post-acquisition transitions when employee turnover is highest.
- Contributor analysis. Git log analysis reveals who touches what code. If 80% of commits in a critical module come from one person, that module is at risk.
- Onboarding time. How long does it take a new developer to ship their first meaningful change? This is a proxy for code quality, documentation, and architectural clarity.
Financial impact: Key-person risk is one of the most common post-acquisition surprises. Retention packages for critical engineers typically cost €30k–€100k per person. If they leave anyway, the knowledge recovery cost is usually higher.
5. Operational health
What you're looking for: Is this system running reliably, or is it held together by manual intervention?
- Uptime and incident history. How often does the system go down? How long does recovery take? Is there an on-call rotation, or does one person's phone ring every time?
- Deployment pipeline. How do changes get to production? Automated CI/CD with tests? Or manual FTP uploads during maintenance windows?
- Monitoring and observability. Are there dashboards? Alerts? Log aggregation? Or does the team find out about problems when customers call?
- Backup and disaster recovery. When was the last tested restore? "We have backups" and "we can restore from backups" are very different statements.
Financial impact: Operational immaturity — manual deployments, no monitoring, no disaster recovery — costs €50k–€150k to remediate and carries ongoing risk until addressed.
How to quantify technical debt
The audit findings need to translate into numbers that inform the deal. We use a simple framework:
| Category | Findings | Remediation Cost | Timeline | Risk if Ignored |
|---|---|---|---|---|
| Security | 12 CVEs (3 critical) | €25k | 3 weeks | Data breach |
| Architecture | Monolith, no scaling path | €120k | 4 months | Cannot support growth |
| Code quality | 40% duplication, no tests | €80k | 3 months | 50% slower development |
| Knowledge | Bus factor = 1 for payments | €50k retention | Immediate | System knowledge loss |
| Operations | Manual deployments, no DR | €35k | 6 weeks | Extended outages |
| Total | €310k |
This total becomes a negotiation input. If the asking price doesn't account for €310k in technical remediation, the acquirer is overpaying.
When to do it
- Before signing the LOI if possible. The technical assessment informs whether to proceed at all.
- During exclusivity at minimum. This is the standard window for due diligence.
- Before integration planning. The findings determine the integration timeline and budget.
The worst time to discover technical debt is three months after the deal closes, when the integration budget is set and the timeline is locked.
If you're evaluating a company's technology as part of an M&A process — or preparing your own system for a potential acquisition — a system audit delivers the structured assessment that turns "we think the code is fine" into evidence-based findings with cost estimates. It's a 2–3 week engagement that can save months of surprises.