I’ve participated in technical due diligence for seven acquisitions over the past decade. Three as part of the acquiring company, four as a CTO being acquired. The experience has given me strong opinions about what matters, what doesn’t, and what most people get completely wrong.

The typical technology due diligence process focuses on the wrong things. Buyers spend weeks cataloguing hardware assets, reviewing software licences, and assessing infrastructure architecture. These things matter, but they’re rarely where the deal-breaking risks hide.

What Buyers Usually Ask

The standard technology due diligence checklist looks something like this:

• Infrastructure inventory (servers, networks, storage)
• Software licence compliance
• Cybersecurity posture assessment
• Application architecture overview
• Disaster recovery and business continuity plans
• IT staffing and organisational structure
• Technology budget and spending trends

These are all legitimate areas of inquiry. A competent buyer should review all of them. But they’re table stakes—the things you check to confirm nothing is obviously broken. The real risks are subtler.

What Actually Matters

Technical Debt Quantification

Every software company has technical debt. That’s not a problem in itself. The problem is when nobody has quantified it or has a realistic plan to address it.

I’ve seen acquisitions where the target company’s product looked impressive in demos but was held together by workarounds, hardcoded configurations, and decade-old libraries with known vulnerabilities. The code worked, but extending it or integrating it with the acquirer’s systems would require a near-complete rewrite.

Estimating technical debt properly requires code review by experienced engineers—not a superficial scan by an automated tool, but actual humans reading the code and understanding the architectural decisions. What are the test coverage levels? How coupled are the components? How much of the code is understood by more than one person?

I’d estimate that inadequate technical debt assessment has contributed to at least 30-40% of the acquisition integration failures I’ve observed. The Harvard Business Review has published extensively on M&A failure rates, and while technology isn’t always the primary cause, it’s a contributing factor far more often than deal documents suggest.

Key Person Dependencies

This is the risk that keeps me up at night during acquisitions.

In most technology companies with under 200 employees, there are two or three people who hold critical institutional knowledge. They understand why the system was designed a certain way. They know where the fragilities are. They can fix things that nobody else can fix.

When those people leave after an acquisition—and they frequently do, because cultural integration is hard and retention bonuses only last so long—the acquirer discovers that they’ve bought a system they can’t maintain.

During due diligence, I always want to know: who are the critical knowledge holders? What documentation exists? What happens if they leave in month seven of a twelve-month integration?

If the answer to that last question is “we’d be in serious trouble,” then the retention strategy for those individuals needs to be part of the deal structure, not an afterthought.

Data Quality and Governance

The target company claims to have ten years of customer data. Great. But what’s the quality of that data? Is it normalised? Is it consistent? Are there duplicates? Are the privacy consents properly documented?

In Australian M&A, the Privacy Act 1988 creates specific obligations around the transfer of personal information during corporate transactions. If the target company’s data governance is poor—consent records are incomplete, data retention practices are inconsistent, or data has been shared with third parties without proper authorisation—the acquirer inherits those compliance risks.

I’ve seen post-acquisition privacy remediation projects cost hundreds of thousands of dollars. That cost should be factored into the deal price, but it often isn’t because nobody looked closely enough during due diligence.

Integration Complexity

The acquirer’s investment thesis usually assumes that systems will be integrated within 12-18 months. In my experience, that timeline is optimistic by a factor of two.

Integration complexity scales exponentially with the number of systems involved. If the target has five core systems and the acquirer has five core systems, you don’t have ten integration points—you have potentially twenty-five, plus all the edge cases, data transformations, and process changes that go with them.

The best due diligence processes include a preliminary integration architecture review. Before the deal closes, experienced architects from both sides should sit down and map out how the systems will coexist and eventually converge. This exercise almost always reveals complications that the deal team hadn’t considered.

Red Flags I Watch For

Some patterns consistently signal deeper problems.

No documentation and pride about it. “Our team is so good, they don’t need documentation.” No—your team is so busy they haven’t documented anything, and when they leave, the knowledge goes with them.

Recent re-platforming just before the sale. Companies sometimes rush modernisation efforts before going to market to make their technology stack look more attractive. Fresh code that hasn’t been tested in production is riskier than stable legacy code.

Single vendor dependency for critical functions. If one vendor disappearing would cripple the business, that’s a risk that needs pricing into the deal.

No automated testing. A codebase without automated tests is a codebase that can’t be safely modified. Every change carries deployment risk.

Revolving door in the engineering team. High turnover in the eighteen months before a sale suggests either cultural problems or knowledge that the company is being shopped.

My Advice to CTOs Being Acquired

If you’re on the other side of this process, being evaluated rather than evaluating, my advice is straightforward: be honest. Disclose the technical debt. Be transparent about key person risks. Show your warts.

The temptation to present a sanitised picture of your technology is strong, especially when your equity value depends on the deal going through. But sophisticated buyers will find the problems eventually—either during due diligence or during integration. Finding them during integration is worse for everyone.

I’ve found that radical transparency during due diligence actually builds confidence rather than destroying it. Buyers aren’t expecting perfection. They’re expecting honesty and a realistic plan for addressing known issues.

The deals that fail aren’t the ones where problems were disclosed upfront. They’re the ones where problems were hidden and discovered too late.