I’ve been involved in the IT due diligence process for nine acquisitions over my career. In seven of them, the technology assessment was an afterthought—a checklist exercise squeezed into the final two weeks before the deal closed. The acquiring company’s deal team would send over a template asking for server counts, software licences, and security certifications. The target would fill it in. Everyone would nod and move on.

Then the integration starts, and reality hits. Incompatible systems, undocumented dependencies, security exposures that weren’t in the spreadsheet, and technical debt so deep it would take two years and millions of dollars to address. According to McKinsey’s research on M&A technology integration, technology issues are the primary driver of value destruction in 30% of acquisitions. That’s not a small edge case. That’s nearly a third of deals.

What Standard Due Diligence Covers (And Why It’s Insufficient)

The typical IT due diligence checklist focuses on inventory: What hardware do you have? What software licences exist? Are you compliant with data protection regulations? Do you have ISO 27001 certification?

These questions aren’t wrong. They’re just surface-level. Knowing that a company runs 47 servers on AWS and holds a current ISO certification tells you almost nothing about integration risk, ongoing costs, or hidden liabilities.

The real risks live deeper.

Where Value Gets Destroyed

Integration complexity. The target company’s ERP doesn’t talk to your ERP. Their CRM uses a different data model. Their customer identity system is custom-built and doesn’t support federation. Each of these gaps represents months of integration work and significant cost. I’ve seen integration budgets blow out by 300% because the due diligence phase didn’t assess system interoperability.

Technical debt that’s been hidden. Every company has technical debt. The question is how much and where. During due diligence, the target company has every incentive to downplay it. That legacy system running core business logic on a version of Java that reached end-of-life in 2019? They’ll describe it as “stable and reliable.” The reality is that it’s a ticking bomb that can’t be patched, can’t scale, and will need to be replaced within 18 months of acquisition.

Key person dependencies. In many mid-market companies, critical systems are maintained by one or two people. If those people leave post-acquisition—which happens frequently, since acquisitions are unsettling—you lose the ability to operate or modify systems that you’ve just paid millions to acquire. The Australian Computer Society’s 2025 workforce report highlighted that 34% of IT professionals consider leaving within six months of an acquisition.

Shadow IT and SaaS sprawl. The formal IT inventory captures maybe 60-70% of the technology actually in use. Marketing has their own analytics tools. Sales runs a CRM add-on nobody in IT knows about. These unmanaged tools often contain sensitive data, lack proper access controls, and create compliance exposure.

What Proper IT Due Diligence Looks Like

Architecture deep dive. Don’t just ask what systems exist. Map how they connect, where the data flows, and what breaks if any single component is removed. This requires technical people in the room, not just financial analysts with a checklist. Two to three days of interviews with the target’s engineering and operations teams is the minimum.

Code and infrastructure review. For technology companies or businesses where software is a core asset, you need to actually look at the code. Automated scanning tools can flag dependency vulnerabilities, outdated libraries, and code quality issues in hours. The investment is trivial compared to the risk of acquiring a codebase that needs to be rewritten.

Licensing audit. Software licence compliance is a minefield. The target might be running Oracle on more cores than they’re licenced for, or using Microsoft products under an agreement that doesn’t transfer with the acquisition. A licence audit before close protects you from vendor true-ups that can run into the hundreds of thousands.

Retention risk assessment. Identify the three to five people whose departure would cause the most operational damage. Understand their compensation, satisfaction, and likelihood of staying post-acquisition. Build retention packages before the deal closes, not after.

Integration cost modelling. Based on the architecture review, build a realistic model of what integration will cost and how long it will take. This should include system migration, data cleansing, process alignment, security remediation, and licence rationalisation. Feed this directly into the deal valuation—if integration costs $5 million more than expected, that should adjust the purchase price.

The Time to Get This Right

IT due diligence needs to start earlier and take longer than most deal teams allocate. Two weeks at the end of a 90-day exclusivity period isn’t enough. Technology assessment should run in parallel with financial and legal due diligence from the start.

The cost of thorough IT due diligence is a rounding error on most deal values. A 200-hour technical assessment for a $50 million acquisition might cost $80,000-$120,000. Compare that against the millions routinely lost to integration surprises.

Yet deal teams keep skipping it, or treating it as a formality. And acquirers keep learning the same expensive lesson: the technology risks you don’t investigate before the deal closes are the ones that eat your returns after.