IT due diligence checklist for M&A

Mergers and acquisitions fail for many reasons, but one of the most preventable is poor IT due diligence. When the technology estate of an acquired company turns out to be significantly worse than expected, post-close integration costs balloon, timelines slip, and the business case that justified the deal starts to unravel.

I have led IT integration work for acquisitions ranging from small bolt-ons to complex multi-site mergers. In every case, the deals that went smoothly shared one thing in common: thorough pre-close IT due diligence. The ones that struggled almost always had gaps in the pre-close assessment that only became visible once the deal was signed.

This checklist covers what IT leaders, operating partners, and transaction teams need to evaluate before closing. It is structured around the areas that matter most: infrastructure and systems, security and compliance, team and contracts, and integration complexity.

Why IT due diligence is different from financial due diligence

Financial due diligence surfaces liabilities on the balance sheet. IT due diligence surfaces liabilities that will not appear on the balance sheet until after close.

A legacy ERP system with no supported upgrade path. A security incident that has not been disclosed. A critical SaaS vendor contract that does not transfer on change of control. Technical debt so severe that the entire platform needs rebuilding rather than integrating. These risks are invisible to financial auditors but can each independently destroy the value of an acquisition.

The goal of IT due diligence is to answer three questions before you commit:

1. What will it actually cost to integrate this technology estate?
2. What risks are we inheriting, and are any of them disqualifying?
3. Does the IT capability match the business model we are buying?

The checklist below is structured to answer each of these questions.

Section 1: Infrastructure and systems inventory

The starting point is a clear inventory of what you are acquiring. This sounds basic, but in practice many targets do not have a current and accurate asset register.

1.1 Servers and hosting

• Current server inventory (on-premise, colocation, cloud) with age and support status
• Cloud provider accounts and spend - are they under a centralised billing structure or scattered across personal accounts?
• Hosting contracts and notice periods for any colocation or managed hosting
• Disaster recovery and backup configuration - when were backups last tested?
• Network topology and any third-party managed network services

1.2 Applications and platforms

• Full application inventory - every system in use, including shadow IT where discoverable
• ERP and core operational systems: vendor, version, support status, licence model
• Customer-facing platforms: architecture, hosting, SLA, capacity headroom
• SaaS subscriptions: who holds the contracts, what are the costs, do they transfer on change of control?
• Custom-built applications: documentation quality, source code ownership, developer knowledge retained in the business?

1.3 Data and integrations

• Where is customer data stored and under what jurisdiction?
• What are the key system-to-system integrations, and how fragile are they?
• Is there a data warehouse or analytics infrastructure, and is it fit for purpose?
• Any known data quality issues that would affect post-close reporting?

The systems inventory is also where you assess integration complexity. A target running modern cloud-hosted SaaS on standard platforms is fundamentally easier and cheaper to integrate than one running on-premise legacy systems with bespoke integrations.

Section 2: Security and compliance posture

Security due diligence deserves its own section because the risks here are categorically different - they can be both immediately material (a breach in progress) and difficult to price precisely (regulatory exposure you cannot fully quantify pre-close).

2.1 Security baseline

• Has the target had a third-party penetration test in the last 12 months? What were the findings?
• Is there a documented information security policy and when was it last reviewed?
• How is access management handled? Is there an IAM system, or is it ad hoc?
• What endpoint protection is in place, and is it centrally managed?
• Is MFA enforced for all externally accessible systems, including email and SaaS?
• Has there been any security incident, breach, or near-miss in the last three years? If so, what was the remediation?

2.2 Compliance and certification

• What regulatory frameworks apply to the target's data processing activities? (GDPR, PCI DSS, HIPAA, ISO 27001, SOC 2, etc.)
• Are there active certifications and what is their renewal status?
• Have there been any regulatory investigations, fines, or enforcement notices?
• Is there a GDPR-compliant data processing register and a documented lawful basis for processing?
• Are data processor agreements in place with all relevant third parties?

2.3 Technical debt and security risk

• What is the patching cadence for operating systems, middleware, and applications?
• Are there known end-of-life systems still in production?
• Is there a vulnerability management programme, or is patching reactive?

My security consulting services include pre-acquisition security assessments that can rapidly baseline the target's security posture and identify material risks before close. This is particularly valuable when the acquirer's own security standards are significantly higher than the target's - the gap between the two becomes a post-close programme of work.

Section 3: Contracts, licences, and IT team

3.1 Vendor contracts

• Software licence agreements: are licences per-seat, per-entity, or per-user? Do they need to be renegotiated post-close?
• Change of control clauses: does any key vendor contract have a change of control provision that could trigger renegotiation or termination?
• Key SaaS contracts: pricing, renewal dates, notice periods, data portability provisions
• Managed service provider agreements: scope, SLA, notice period, any restrictive terms?
• Any IT contracts that are materially above or below market rate?

3.2 IT team

• Headcount, roles, and reporting structure of the IT function
• Are any key IT staff on notice, or is there known attrition risk?
• What is the split between permanent employees and contractors?
• Are there key-person dependencies - systems or knowledge held by one individual?
• What is the IT culture? Is the team reactive (break-fix) or proactive (strategic)?

3.3 Intellectual property

• Who owns the intellectual property in any custom software built by the target?
• Are there any open source licences in the codebase that impose obligations on the acquirer?
• Has the target ever had an IP dispute with a technology vendor?

Section 4: Integration complexity and cost estimate

The final section is where the due diligence findings translate into an integration cost estimate. This is the number that feeds back into the deal model.

4.1 Integration scenarios There are typically three approaches to post-close IT integration, and the choice shapes the cost estimate significantly:

• Full integration: The acquired entity's systems are migrated onto the acquirer's platform. This is the most expensive and disruptive option, but it produces the most operating leverage long-term.
• Federated (keep separate): Both entities run their own systems, connected at the data level. This is lower initial cost but creates ongoing duplication and data reconciliation overhead.
• Hybrid: Core systems integrate; peripheral systems stay separate. This is the most common approach for bolt-on acquisitions.

For each key system identified in Section 1, the integration scenario drives the cost estimate. A cloud-hosted SaaS on standard platforms integrates cheaply. A bespoke on-premise ERP with undocumented integrations does not.

4.2 Red flags that change the deal maths

Not every IT issue is a dealbreaker, but some findings materially change the post-close investment required:

• Active security incidents or undisclosed breaches
• End-of-life core systems with no clear upgrade path
• SaaS contracts that do not transfer and require full renegotiation
• Critical systems held in a single employee's personal accounts
• Regulatory compliance gaps that require immediate remediation
• Architecture that is fundamentally incompatible with the acquirer's platform

When I advised on the integration work described in my M&A IT integration case study, the pre-close assessment identified a core platform that needed replacement rather than integration. That finding changed the integration timeline from three months to twelve, and the budget accordingly. Knowing this before close allowed the deal team to adjust the price rather than absorb the cost post-close.

Making the most of limited access pre-close

One practical challenge with IT due diligence is that access to the target's systems and team is often restricted, particularly in competitive processes. Sellers are understandably cautious about sharing detailed technical information with parties who may not ultimately acquire the business.

A practical approach is to prioritise ruthlessly. The most valuable pre-close findings are:

1. Disqualifying risks - active security incidents, regulatory non-compliance, major contractual blockers
2. Material cost differences - the gap between the assumed integration cost and the actual integration cost
3. Key-person dependencies - IT capability that walks out the door post-close if retention is not addressed

Everything else can be addressed through structured representations and warranties or through a post-close remediation programme, provided it is properly scoped and budgeted.

My IT management consulting and IT project management services cover both the pre-close due diligence assessment and the post-close integration programme. If you are working on a transaction and need an independent perspective on the IT estate, get in touch to discuss your timeline and what is needed.

---

IT due diligence done well does not slow down deals. It gives the deal team the information they need to price risk accurately - and it gives the integration team a head start on the work that begins on day one after close.