IT Due Diligence Checklist for M&A: 25-Point Framework

The acquisition looked clean on paper. Strong revenue, healthy margins, a customer base that fit the acquirer’s strategy. The letter of intent was signed. Then the IT due diligence team walked in.

They found three enterprise software licenses deployed across 40% more seats than contracted. An ERP agreement with a change-of-control clause that gave the vendor the right to terminate on 30 days notice. A data center lease expiring six weeks after close. A custom-built application whose original developer had left the company three years prior — no documentation, no source code repository, no one who understood it. And a HIPAA compliance program that had never been formally audited.

None of this killed the deal. But it added $1.4 million in remediation costs, shifted $600,000 of value to the seller’s side in price adjustment negotiations, and pushed the integration timeline out by four months. These were not exotic problems — they are exactly the problems IT due diligence is designed to surface before you are contractually committed.

IT due diligence is not a technical formality. It is where material deal risk lives. This guide gives you the 25-point checklist across five categories that acquirers use to uncover hidden costs, non-assignable contracts, security liabilities, and integration risks — before they become post-close emergencies.

Why IT Due Diligence Matters in M&A

Most due diligence processes spend 80% of their time on financials and legal review. IT gets a cursory look — a few questions in the management presentation, a vendor list, maybe a high-level infrastructure diagram. This is backwards.

Technology is where the surprises hide. Financial statements are audited. Legal agreements are reviewed by counsel. But the IT environment is often undocumented, inconsistently managed, and opaque even to the company’s own leadership. The target’s CFO can tell you exactly what the software spend is. They cannot tell you whether those licenses are correctly deployed, whether the contracts are assignable, or whether there is a critical dependency on a vendor who can walk away after close.

Three categories of risk dominate IT M&A failures:

Hidden costs: True-up liabilities from over-deployed licenses, undocumented custom development work that must be maintained, technical debt that must be resolved before systems can be integrated, and infrastructure upgrades required to bring the target’s environment to acquirer standards. These costs rarely appear in the financial statements — they surface post-close as budget overruns.

Integration risks: Systems that cannot connect to the acquirer’s environment without significant re-engineering, duplicate platforms that must be rationalized (two ERP systems, two CRM systems), data migration complexity that was underestimated, and single-vendor dependencies that make the integration timeline contingent on a third party’s cooperation.

License transfer and contract complications: Software licenses that do not survive a change of ownership, vendor agreements with termination-for-convenience clauses triggered by acquisition, SaaS subscriptions that prohibit assignment without consent, and managed service agreements where the relationship is tied to specific individuals who are departing post-close. See our guide on negotiating IT vendor contracts for the specific clauses that create post-acquisition exposure.

The 25-Point IT Due Diligence Checklist

This checklist is organized into five categories: Infrastructure, Applications, Vendor Contracts, Security and Compliance, and People and Process. Work through each category in order — infrastructure informs application assessment, and both inform contract review.

Category 1: Infrastructure (Items 1–5)

• Item 1 — Server and hardware inventory. A complete list of physical and virtual servers, network equipment, storage systems, and end-user hardware. Key questions: What is the age and end-of-support status of each asset? What is owned vs. leased, and what are the lease terms? Does the acquirer’s infrastructure standard require replacement of any equipment? Hardware refresh costs are easy to quantify but routinely missed in deal modeling.
• Item 2 — Cloud accounts and contracts. A full inventory of cloud accounts across all providers (AWS, Azure, GCP, and any niche platforms). For each: current monthly spend, contractual commitment (reserved instances, committed use discounts), and whether the account is under a reseller or direct agreement. Cloud contracts often contain minimum commitment clauses — an acquirer who wants to migrate the target to their own cloud must budget for contract buyout costs. Also flag any credits or grants that will expire or not transfer.
• Item 3 — Network topology and connectivity. Network architecture diagrams showing site connectivity, firewall topology, and internet egress points. Key questions: Are there dedicated circuits (MPLS, SD-WAN) with long-term contracts? What are the bandwidth commitments? How are remote users authenticated? Network integration is on the critical path of Day 1 readiness — if the target’s employees cannot access acquirer systems on Day 1, operations are disrupted. Understanding the current network architecture is the prerequisite for planning Day 1 integration correctly.
• Item 4 — Backup, disaster recovery, and business continuity. Current backup architecture (what is backed up, where, how often, and how tested), RPO and RTO commitments, and DR testing history. Key questions: When was the last DR test, and did it succeed? Is the DR environment co-located with production (which defeats the purpose)? Are backups immutable (critical for ransomware resilience)? Acquirers frequently discover that a target’s “DR plan” is a document with no tested procedures — a liability that becomes yours on Day 1.
• Item 5 — Capacity planning documentation. Current utilization metrics for compute, storage, and network — and projections against planned growth. Look for hidden scalability problems: a database server running at 90% CPU utilization, a SAN with 18 months of storage runway, a network link consistently exceeding 80% utilization. These are not current failures; they are time-bombs that can detonate during the integration period when additional load is placed on systems. Budget for capacity expansion before integration begins, not after systems start failing.

Category 2: Applications (Items 6–10)

• Item 6 — Complete software inventory with versions. Every application in use: name, version, vendor, deployment model (on-premise vs. SaaS vs. hosted), number of licensed users, and actual deployment count. The gap between licensed and deployed users is your true-up liability. Automated discovery tools (Lansweeper, Flexera, Oomnitza) are more reliable than self-reported inventories — targets consistently under-count shadow IT and departmental tools purchased outside IT’s awareness. Request an automated discovery report rather than a manually assembled spreadsheet.
• Item 7 — ERP and CRM systems assessment. ERP and CRM are the highest-integration-complexity systems in any acquisition. For each: version and support status, customization extent (heavily customized ERPs take 12–24 months to integrate or migrate), integration points with other systems, and data model compatibility with the acquirer’s equivalent system. Two heavily customized ERP instances that need to be consolidated is a multi-year project. Model this before close, not after.
• Item 8 — Custom-built applications and source code ownership. Every internally developed application: what it does, what business process depends on it, who built it (internal team, external contractor, or departed employee), where the source code lives, and whether development documentation exists. Custom applications built by contractors often have IP complications — check development agreements to confirm that intellectual property was fully assigned to the company. Source code stored only on individual machines is a total loss risk.
• Item 9 — SaaS subscriptions and shadow procurement. The full list of SaaS tools in use, particularly departmental purchases that may not appear in IT’s inventory. Review accounts payable for software vendors and compare against the IT-reported inventory — the gap is shadow IT. For each SaaS tool, confirm: Is the contract in the company’s name or an individual employee’s personal account? Are there API integrations between this tool and other systems that create a dependency? Departmental tools purchased on personal credit cards are not corporate assets and cannot be transferred.
• Item 10 — System integration and API dependency map. A map of all system integrations: what connects to what, through which mechanisms (API, flat-file, middleware), and what breaks if any one integration fails. Integration architecture diagrams are often absent even in well-managed IT environments — reconstruct through technical interviews with IT staff. Hidden integration dependencies are the most common source of post-close surprises: a system that “doesn’t matter much” turns out to feed critical data to three other systems, and consolidating it requires re-engineering those dependencies.

Category 3: Vendor Contracts (Items 11–15)

Vendor contract review is where deal-structuring decisions are tested against reality. Many acquirers skip this in detail; the ones who don’t find problems that change the deal terms. For a deeper treatment of the contract clauses that create the most post-acquisition risk, see our guide on IT vendor risk assessment.

• Item 11 — Assignability clauses across all material contracts. Every vendor contract above a materiality threshold (typically $10,000/year or $25,000 total contract value) must be reviewed for: (a) explicit assignment prohibition, (b) requirement for vendor consent to assign, and (c) change-of-control provisions. These are three different legal mechanisms requiring different responses. Explicit prohibitions mean the contract terminates if the business is sold. Consent requirements mean you must contact the vendor for approval before or immediately after close. Change-of-control provisions often give the vendor termination rights or price renegotiation rights — and in stock purchases, they apply even though no formal assignment occurred.
• Item 12 — Auto-renewal dates and notice windows. Every contract with an auto-renewal clause requires a calendar entry for the notice deadline — the date by which you must notify the vendor of non-renewal. If the target has a contract that auto-renews 30 days after close, and your integration plan calls for consolidating to the acquirer’s equivalent system, you have 30 days post-close to provide notice or you are locked in for another term. Map every renewal date against the integration timeline. Renewals in the first 90 days post-close are high-risk: they often get missed in the integration transition, binding the acquirer to contracts for systems they plan to decommission. See our full guide on IT vendor contract negotiation for the notice clause patterns to watch for.
• Item 13 — Termination fees and early exit costs. For every contract with a term longer than 12 months remaining, calculate the termination liability: early termination fee, remaining minimum commitment balance, or both. These liabilities flow directly to integration cost modeling. A target with $200,000 in remaining contract commitments for systems the acquirer plans to decommission has $200,000 in integration cost that belongs in the deal model — not discovered on the first integration committee call. Also review whether there are performance-based termination rights the target holds that would allow exit without penalty.
• Item 14 — Vendor concentration risk. How dependent is the business on any single vendor? Calculate what percentage of IT operations would be disrupted if the top three vendors became unavailable. Single-vendor dependencies create negotiating leverage problems post-acquisition: a vendor who knows they are the only option for a critical system can reprice aggressively. Also assess the financial stability of top vendors — a managed service provider that is financially fragile is a continuity risk the acquirer inherits.
• Item 15 — SLA compliance history. Request SLA performance reports for the 12–24 months prior to the acquisition for all material vendor relationships. Consistent SLA misses that were never escalated or remedied signal a vendor relationship that has degraded — and a target that did not manage vendors effectively. These contracts may have liquidated damages provisions that were never invoked, and the underlying service quality problems will transfer to the acquirer.

Category 4: Security and Compliance (Items 16–20)

• Item 16 — Penetration test results and vulnerability management. Request the most recent penetration test report (internal and external) and the remediation status of findings. Key questions: How old is the most recent pentest? Were critical and high findings remediated, and on what timeline? Is there an ongoing vulnerability management program, or was the pentest a one-time event? A target with an 18-month-old pentest and no evidence of remediation of critical findings has known vulnerabilities that transfer on Day 1. External vulnerability scans can supplement target-provided reports — run your own scan with permission rather than relying solely on self-reported results.
• Item 17 — Compliance certifications and audit history. For each applicable framework (SOC 2, ISO 27001, HIPAA, PCI-DSS, GDPR), confirm: Is the certification current? Who performed the audit? What exceptions were noted? When does the certification expire? A SOC 2 report from a small, unrecognized auditor with zero exceptions is a yellow flag, not a green one. Also confirm that the compliance program covers the systems and data the acquirer cares about, not just a narrow subset defined in the original scope.
• Item 18 — Data breach and incident history. Require disclosure of all security incidents, data breaches, and regulatory notifications in the prior 36 months — including incidents that were internally contained and not publicly disclosed, vendor-side breaches that affected the target’s data, and regulatory inquiries (even if resolved). Undisclosed breaches are a liability that transfers post-close. If a breach triggered GDPR notification obligations that were not met, that regulatory exposure survives the acquisition. Representations and warranties insurance is essential coverage for exactly this scenario.
• Item 19 — Access control audit and identity management. Who has privileged access to what? Review: administrative accounts in Active Directory or equivalent, service accounts with elevated permissions, third-party vendor access (MSP remote access, SaaS administrator roles), and former employee accounts. Excessive privileged access is both a security risk and a compliance problem. Former employees with active accounts are common in SMB acquisitions. Confirm that offboarding procedures exist and are actually followed, not just documented.
• Item 20 — Cyber insurance coverage. Policy limits, coverage scope (first-party vs. third-party), exclusions (particularly nation-state attack exclusions, which are increasingly common), and claims history. Key questions: Does the policy survive the acquisition, or does a change-of-control void coverage? Will the acquirer’s policy cover the target post-close, or is there a gap period? Claims history is the best signal of actual security posture — a target with multiple cyber insurance claims in recent years has a recurring problem that current posture has not addressed.

Category 5: People and Process (Items 21–25)

• Item 21 — IT organizational chart and key person risk. Who are the IT staff, what do they own, and which of them are irreplaceable? Key person risk is the most underestimated item in SMB IT due diligence. A five-person IT team where one person is the only one who understands the ERP, the network, and the backup infrastructure is not a five-person team — it is one person with four assistants. Assess: Who are the people whose departure would cause significant operational disruption? What retention mechanisms exist? Are they already interviewing elsewhere?
• Item 22 — Documented runbooks and operational procedures. How much of IT operations is documented vs. stored in people’s heads? Request runbooks for critical operational procedures: system restores, incident response, vendor escalation paths, change management. The absence of documentation does not mean the procedures do not exist — but it means they exist only in specific employees’ minds. If those employees leave during the integration period (which is common), the acquirer inherits undocumented systems with no recovery path except expensive reconstruction.
• Item 23 — Shadow IT inventory. Applications, services, and data repositories that exist outside of IT’s official inventory. Discovered through: accounts payable review (software purchases on non-IT credit cards), user interviews, and network traffic analysis. Shadow IT is a predictable response to IT departments that move slowly, but it creates compliance, security, and integration risk. Data stored in a personal Dropbox account, customer information in a departmental Google Sheet, financial models in an unsanctioned tool — these are the surprises that surface when integration teams try to understand where the data actually lives.
• Item 24 — Vendor relationship contacts and escalation paths. For every material vendor, who is the relationship owner at the target? Is it a named individual (who may leave post-close) or a role-based relationship managed through official channels? Request the vendor contact directory with named contacts, account numbers, and escalation paths for each vendor relationship. Acquirers who cannot reach vendor account managers post-close spend weeks re-establishing contacts that could have been documented in due diligence. This is particularly critical for managed service providers and custom development vendors.
• Item 25 — Change management history and IT governance. How does the target make IT decisions, approve changes, and manage projects? Review: the change management process, the last 12 months of significant IT changes and their outcomes, and any active IT projects in flight at the time of close. Projects in flight are a risk category of their own: a mid-migration ERP upgrade that is 60% complete, a network re-architecture running for eight months, a security remediation project with a hard regulatory deadline. Each in-flight project must be assessed for completion risk, timeline, and budget — and integrated into the Day 1 planning.

Vendor Contract Assignability: What Transfers and What Does Not

Contract assignability is the most legally complex piece of IT due diligence and the one most likely to require counsel who understands both technology contracts and M&A transaction structure. The basic framework:

Contract Type	Typical Assignability	Risk Level
Enterprise software licenses (Microsoft, Oracle, SAP)	Usually requires vendor consent; change-of-control clauses common; true-up triggered at change of ownership	High — true-up costs can exceed $200K
SaaS subscriptions	Most terms of service prohibit assignment without consent; vendor must approve	Medium — usually resolved with notification, but timeline matters
Managed service agreements	Frequently include change-of-control termination rights; MSP may reprice at renewal	High if MSP handles critical infrastructure
Telecom and connectivity contracts	Generally assignable in stock purchases; asset purchases require consent; long minimum terms are the risk	Medium — main risk is minimum commitment buyout
Custom development agreements	Typically assignable as part of business transfer; IP ownership is the key question	Medium — IP assignment verification required
Cloud platform agreements (AWS, Azure, GCP)	Generally assignable with notice; committed use discounts may not transfer to acquirer account	Low-medium — committed use credit loss is the main risk

The vendor contact strategy matters here. Reaching out to vendors before close risks signaling that a transaction is in process. Most M&A counsel will advise against pre-close vendor notification for non-critical contracts. For contracts where consent is required and the vendor relationship is critical, the notification is structured as a condition to close — the deal does not close until consent is obtained. Budget for the possibility that a critical vendor declines consent or demands renegotiation as the price of consent.

License Audit: Avoiding Surprise True-Up Costs Post-Acquisition

Software license true-ups are the most predictable and most consistently overlooked IT due diligence item. Enterprise software vendors conduct post-acquisition audits as standard practice. Microsoft, Oracle, Salesforce, and SAP all have internal teams whose job is to identify license compliance gaps at companies that have recently changed ownership.

The mechanism: most enterprise software licenses are scoped to a named legal entity with a defined user or deployment count. When ownership changes, the vendor has the contractual right (and the practical interest) to verify that the license terms are still being honored. If the acquisition increases user count, consolidates systems in a way that changes deployment counts, or moves licenses across legal entities — all common integration activities — the vendor has grounds for a true-up demand.

The due diligence response is straightforward: conduct a license compliance review before close. For each enterprise software contract, document the licensed user or deployment count, the actual deployed count from an automated discovery tool, and the gap. The gap is the true-up liability. Model it into the deal as a known cost rather than discovering it on receipt of a vendor audit letter six months post-close.

Two scenarios require special attention. First, the target is over-deployed — more users or deployments than the license covers. This is a liability you are inheriting. Quantify it and adjust the purchase price accordingly, or require the seller to cure it pre-close. Second, the post-merger combined headcount changes the license requirement in a way that triggers an upgrade. If the combined company now has 500 Microsoft 365 users and the target had a 200-seat contract, the acquirer must procure the additional seats. This is a predictable integration expense — but it should be in the model before deal close rather than appearing as a surprise in Month 2.

Integration Timeline Planning: Day 1 to Day 180

IT integration is not a single event — it is a phased program with distinct milestones and different risk profiles at each phase. Planning the integration timeline during due diligence, not after close, is what separates integrations that run on schedule from those that expand indefinitely while two parallel IT environments run at double cost.

Common M&A IT Disasters and How to Avoid Them

The same failures repeat across acquisitions with enough consistency to be preventable. These are not exotic scenarios — they are what happens when the 25-point checklist above is skipped.

The Undisclosed Data Breach

A target company experienced a data breach six months before the acquisition closed. The breach was contained internally; no regulatory notification was made (even though GDPR notification was arguably required). The acquiring company discovered the breach during the first post-close IT audit. The regulatory exposure — notification obligations and potential fines — transferred with the acquisition. Avoidance: require explicit representations and warranties on security incident disclosure going back 36 months, back it with representations and warranties insurance, and conduct your own external network scan during due diligence rather than relying solely on target disclosures.

The Non-Assignable ERP License

A $180M acquisition of a manufacturing company closed before the ERP vendor’s change-of-control clause was reviewed. The vendor exercised its right to terminate the license agreement 45 days post-close. The target’s operations depended on this ERP for production scheduling, inventory, and invoicing. Emergency re-procurement and accelerated migration cost $2.1M and caused a six-week operational disruption. Avoidance: review change-of-control provisions in every material software contract before close, and structure consent requirements as closing conditions.

The Shadow IT Data Repository

A technology company’s acquisition team did not discover until 90 days post-close that the target’s sales team had been running customer relationship data through a departmental Salesforce org paid on a personal credit card — in addition to the corporate CRM. The shadow org contained 18 months of customer interaction data, contact information, and deal notes not present in any official system. The data could not be migrated because the corporate CRM data model did not match. Avoidance: shadow IT discovery is non-negotiable — request accounts payable analysis and conduct user interviews during due diligence, not after close.

The Key Person Departure

The target company’s IT director — the only person who fully understood the ERP customizations, the network architecture, and the vendor relationships — accepted a competing offer and resigned three weeks post-close. No documentation existed for any of the systems she managed. The acquirer spent $180,000 in consulting fees over six months reconstructing what she knew. Avoidance: identify key IT personnel during due diligence, assess retention risk, and structure retention agreements as a condition of close for irreplaceable staff.

The Integration That Never Completed

An acquisition closed with the stated intention to migrate the target to the acquirer’s cloud environment “within six months.” Three years later, the target’s data center was still running — costing $280,000/year in facilities, maintenance, and separate IT staff. The integration had stalled because no one owned it with accountability, scope decisions kept expanding, and each expansion pushed the timeline further. Avoidance: integration timelines require a named owner with authority, a defined scope that is locked at Day 30, and a monthly cost-of-delay calculation that makes the economics of delay visible to leadership.

Running IT Due Diligence Without a Large IT Team

Most SMB acquirers do not have a dedicated IT due diligence capability. The team doing financial due diligence is not the same team that should be reviewing firewall configurations and change-of-control clauses. Practical structure for SMB-scale IT due diligence:

Hire a fractional CISO or IT due diligence consultant for the duration of the process. A 40–60 hour engagement with an experienced technology advisor covers the infrastructure, application, and security assessment. Cost: $8,000–$20,000. Value: catching a $200,000 true-up liability or a non-assignable ERP contract justifies this cost on the first deal.

Run the vendor contract review through M&A counsel with technology contract experience. Generic M&A lawyers will spot the change-of-control clauses. Technology-specialized M&A counsel will understand the difference between a perpetual license and a subscription, and what each means for post-close continuity. The contract review can be scoped to material contracts above a defined threshold to manage cost.

Use the due diligence findings to build the Day 1 plan. IT due diligence should produce two outputs: a risk register (with each item quantified and assigned to a responsible party) and the Day 1 IT readiness checklist. These are the deliverables, not just the findings. The due diligence investment is only realized if the findings drive integration planning — a comprehensive IT due diligence report filed and never referenced is sunk cost with no value.

Finally, resist the pressure to shorten the IT due diligence window when deal timelines compress. Financial due diligence is often given 30–45 days; IT frequently gets the last two weeks of that window. This is backwards for deals where technology is material to the business model. Push for concurrent rather than sequential due diligence tracks, and establish the IT due diligence timeline in the letter of intent, not as an afterthought at the start of the exclusivity period.