The brutal reality: most IT surprises surface after you've signed, when the cost to walk away is infinite and the cost to fix climbs every week.
It's common across roll-ups in facilities management, industrial services, and healthcare: the commercial diligence looks clean, the vendor assures you their systems are "modern and cloud-based," and everyone agrees IT should be straightforward. Then on Day One you discover the CRM runs on an Access database, half the customer contracts are scanned PDFs stored on someone's desktop, and the critical field dispatch workflow depends on an Excel macro written by someone who left three years ago.
Here's the math: Gartner reports that 84% of IT integrations fail or experience significant issues, and 83% of data migrations fail or exceed budget. Those aren't edge cases — they're the norm. And for serial acquirers doing multiple deals a year, each unplanned cost and delay compounds across the portfolio.
This isn't about perfection. It's about knowing what you're buying, pricing the real cost of integration, and deciding - before LOI - whether the technical debt is manageable or a deal-breaker. If you're a roll-up doing 3–5 acquisitions a year, every deal compounds complexity. The sixth acquisition is harder than the first, not easier, unless you're intentional about what you're inheriting.
This checklist gives you a structured pre-deal IT assessment framework: what to evaluate, what questions to ask, what findings should trigger renegotiation or a walk. This is built from the reality of mid-market service industry roll-ups where IT is rarely the hero but often the hidden liability.
Why IT Due Diligence Fails in the Middle Market
It's not that IT due diligence doesn't happen - it's that it happens too late, in isolation, and without the right questions.
Problem one: IT gets assessed after commercial and financial diligence, often squeezed into the final weeks before close. By that stage, deal momentum is high, emotional commitment is real, and the pressure is to validate rather than interrogate. Red flags get papered over as "post-close remediation items."
Problem two: IT diligence is siloed. The commercial team is evaluating customer contracts and revenue quality. Finance is stress-testing EBITDA. IT gets handed to a technical consultant who produces a 40-page report on server specs and network topology but doesn't connect it to integration cost, business continuity risk, or your ability to extract consolidated reporting in 60 days.
Problem three: underestimating integration complexity and cost. A vendor might tell you they're "fully cloud-based," but what they mean is they use Gmail and QuickBooks Online while their core dispatch system is a legacy on-premise application with no API. You price integration at £15K and four weeks: the reality is £60K and four months, plus the operational disruption you didn't model.
Problem four: ignoring the people, process, and governance layer. IT due diligence tends to focus on technology assets - what software, what infrastructure - and miss the operational dependencies. Who actually knows how the systems work? Is there documentation? What happens if the IT manager leaves during transition? How is data governed, and who has admin access?
The result: deals close with technical debt priced as zero, integration timelines that assume everything will be straightforward, and a post-close scramble when reality diverges from the optimistic case.
Real Talk: It's not uncommon for the IT "due diligence" to amount to a 30-minute call with the target's office manager. Weeks later, the acquirer discovered the CRM had no API, customer data lived in seventeen Excel files, and nobody could explain how invoicing actually worked. Not because they didn't care - because they didn't know what to ask.
When to Conduct Your M&A IT Assessment
Timing matters. Run IT diligence in parallel with commercial and financial workstreams, not after them. The goal is to inform valuation, deal structure, and post-close planning - not simply to document what you've already committed to buy.
Ideally, IT assessment happens in two phases: a high-level scan pre-LOI to surface deal-breakers, then a detailed audit post-LOI to quantify integration cost and complexity.
Pre-LOI: Early Red Flags and Go/No-Go Indicators
Before you submit a letter of intent, invest a few hours in a targeted IT sanity check. You're not trying to map every workflow or audit every server - you're hunting for red flags that would materially change valuation or make integration unviable.
What to check:
- Critical systems and dependencies: What software runs customer-facing operations? Dispatch, scheduling, invoicing, CRM? Can it scale or integrate, or is it end-of-life?
- Cybersecurity and breach history: Has the company experienced a data breach or ransomware incident in the past three years? Are they compliant with basic standards (GDPR, Cyber Essentials, industry-specific regulations)?
- Licencing and contractual lock-in: Are they mid-contract on expensive ERP or vertical software with punitive exit clauses? Are licences current and transferable?
- IT team and knowledge concentration: Is there one person who holds all the IT knowledge? What's their retention risk?
- Shadow IT and undocumented systems: Quick question to department heads: "What tools do you use every day that IT didn't set up?" The answers will surprise you.
Go/no-go triggers:
- Non-transferable or non-scalable core systems (e.g., bespoke legacy ERP with no vendor support)
- Recent or ongoing cybersecurity incidents with regulatory exposure
- Dependence on a single IT person with no documentation or succession plan
- Licencing liability that materially impacts deal economics (e.g., £100K true-up on under-licenced software)
If any of these emerge, you have three options: renegotiate price, require the seller to remediate pre-close, or walk. Discovering them post-close turns them from bargaining chips into your problem.
Post-LOI: Deep Dive Technology Due Diligence
Once LOI is signed and you have deeper access, conduct a structured audit covering the full IT landscape: applications, infrastructure, data, suppliers, contracts, and team capability. This phase should produce three outputs:
- Integration complexity and cost estimate: What needs to be migrated, consolidated, or replaced? What's the realistic timeline and budget?
- Risk register: Security, compliance, continuity, and operational risks that need mitigation.
- Day 1 and Day 100 roadmap: What must happen immediately for business continuity, and what can be deferred?
You'll use these to finalise the purchase agreement (including any seller reps and warranties on IT), allocate post-close budget, and brief your internal or external integration team.
At PMI Stack, we typically run this phase in 2–3 weeks, combining stakeholder interviews, system walkthroughs, and - critically - the Closet Server Test: a physical site visit to find the server in the storage cupboard, the USB drives with customer data, and the undocumented kit that nobody mentioned in the data room.
The Seven-Part IT Due Diligence Framework
Here's a structured checklist for your diligence team. Each section includes the questions to ask, the evidence to request, and the red flags that should escalate to deal risk or integration cost.
Systems Inventory and Architecture Mapping
Objective: Understand what software the business actually runs on, how systems connect, and where operational dependencies lie.
What to request:
- Complete list of all software and SaaS subscriptions (including departmental tools, not just IT-managed systems)
- Architecture diagrams or system maps (if they exist - they often don't)
- User counts and roles per system
- Integration or data flow maps between systems
Questions to ask:
- What software is business-critical? If it went down for a day, what stops?
- How do systems talk to each other? APIs, manual exports, or someone re-keying data?
- Are there any bespoke or customised applications? Who built them, and is the source code available?
- What happens during peak periods (e.g., seasonal demand)? Do systems cope, or do workarounds kick in?
Red flags:
- No clear inventory ("We'll get back to you on that")
- Core workflows dependent on unsupported legacy software or end-of-life platforms
- Heavy reliance on manual processes or Excel for operational data (indicates systems aren't fit for purpose)
- Bespoke applications with no source code, documentation, or ongoing vendor support
Integration impact: If the target's core systems don't integrate with yours and can't be replaced easily, you're looking at either running parallel systems indefinitely (expensive, risky) or a costly migration project. Price that before you close.
Vendor Contracts, Licencing, and True Run Rate
Objective: Quantify the real cost of IT, uncover licencing liabilities, and identify contractual lock-in that constrains your post-close options.
What to request:
- Full list of IT vendor contracts (SaaS subscriptions, licences, support agreements, hosting, telecoms)
- Contract end dates, notice periods, auto-renewal terms, and termination clauses
- Licencing agreements for all commercial software (especially ERP, CRM, Microsoft/Google Workspace, Adobe, AutoCAD, vertical applications)
- Invoices or statements for the past 12 months to verify actual spend
Questions to ask:
- What's the total annual IT spend, including software, licences, hosting, support, and telecom?
- Are all users properly licenced? (Under-licencing creates liability: over-licencing is waste.)
- Are there any upcoming renewals or price increases?
- What's the notice period and exit cost if we want to terminate or migrate away?
- Are licences transferable in an acquisition, or do they require renegotiation?
Red flags:
- Significant under-licencing (risk of vendor audit and back-payment, plus penalties)
- Long-term contracts with punitive exit clauses on software you plan to replace
- "Shelfware" - licences paid for but not used, indicating poor governance
- Verbal agreements or "handshake deals" with vendors (no legal protection)
- Surprise spend: software subscriptions paid on personal credit cards or outside IT's visibility (shadow IT)
Case in Point: A facilities management roll-up discovered post-close that the acquired company had been under-licenced on their field service software for two years. The vendor audited them during integration, resulting in a £48K true-up bill that wasn't in the deal model. That's a diligence failure, not bad luck.
Data Quality, Ownership, and Migration Risk
Objective: Assess whether the data you're acquiring is accurate, structured, compliant, and migratable - or whether you're inheriting a mess that will take months to clean.
What to request:
- Data inventory: what data exists, where it's stored, who owns it, and how it's structured
- Data governance policies (if any)
- Evidence of GDPR compliance: privacy notices, data processing agreements, subject access request logs, breach notification procedures
- Sample data exports from core systems (CRM, ERP, customer database, finance)
Questions to ask:
- How clean is the data? Duplicates, incomplete records, inconsistent formatting?
- Is customer data centralised, or spread across multiple systems and spreadsheets?
- Who has access to sensitive data, and how is it controlled?
- Has the business ever conducted a data audit or cleanup?
- What's the data residency and sovereignty position? (Important if you operate cross-border.)
- Are there any third-party data-sharing agreements or obligations that survive the acquisition?
Red flags:
- Data lives in Excel files, email inboxes, or local drives rather than structured systems
- No GDPR compliance programme or evidence of lawful data processing
- High duplication or poor data quality (indicates migration will require extensive cleaning)
- Lack of data ownership or accountability (nobody knows who's responsible)
- Data processing agreements missing or non-compliant with current regulations
Migration reality check: Poor data quality is the single biggest source of migration delay and cost overrun. If 30% of CRM records are duplicates and addresses are inconsistent, you can't just "lift and shift." Budget time and cost for data cleansing, or accept that you'll migrate dirty data and deal with the consequences in BAU.
Infrastructure, Security, and Compliance Posture
Objective: Understand the target's IT infrastructure, cybersecurity maturity, and regulatory compliance - and quantify the risk and remediation cost.
What to request:
- IT infrastructure overview: on-premise servers, cloud hosting, network architecture, backup and disaster recovery
- Cybersecurity policies and controls: firewalls, endpoint protection, patch management, access controls, MFA
- Evidence of security certifications (ISO 27001, Cyber Essentials, SOC 2)
- Incident history: any breaches, ransomware, data loss, or security events in the past three years
- Compliance documentation for relevant regulations: GDPR, industry-specific standards (e.g., CQC for healthcare, PCI-DSS if handling card payments)
Questions to ask:
- When was the last penetration test or security audit?
- Is multi-factor authentication enforced across all systems?
- How are backups managed, and have they been tested?
- What's the patch management process? Are systems up to date?
- Who has admin access to critical systems, and is it logged?
- Have there been any cybersecurity incidents or near-misses?
Red flags:
- No documented security policies or controls
- History of breaches or ransomware attacks, especially if not disclosed during diligence
- End-of-life infrastructure (e.g., servers running unsupported Windows versions)
- Lack of MFA, weak password policies, or shared admin credentials
- Poor or untested backup and disaster recovery
- Regulatory non-compliance (particularly GDPR in the UK/EU)
Warning: Cybersecurity incidents in the 12–24 months pre-acquisition can create post-close liability, especially if notification obligations weren't met or customers were affected. If the target has been breached and hasn't disclosed it, that's a material misrepresentation and a reason to renegotiate or walk.
Integration Complexity and Timeline Estimate
Objective: Translate IT findings into a realistic integration plan - what needs to happen, in what order, at what cost, and over what timeline.
What to assess:
- Integration approach: High-Touch (full consolidation), Medium-Touch (selective integration), or Low-Touch (financial visibility only)
- System compatibility and migration feasibility
- Day 1 requirements: what must be in place for business continuity?
- Day 100 milestones: what needs to be integrated for reporting, compliance, and operational advantage?
Questions to ask:
- Does strategic intent require full integration, or can this acquisition run semi-autonomously?
- Which systems must be consolidated for reporting visibility (finance, CRM) vs. which can stay separate (operational tools)?
- Can the target's systems scale to support growth, or will they need replacement regardless of integration?
- What's the critical path? (E.g., email and file storage first, then finance, then CRM, then ERP.)
- What are the dependencies and risks? (E.g., data migration blocks CRM consolidation.)
Red flags:
- Assuming integration will be "quick and easy" without evidence
- No consideration of business disruption or user adoption
- Underestimating data migration complexity
- Lack of rollback plan if migration fails
Integration impact: If you're a roll-up doing 3–5 acquisitions a year, integration complexity compounds. The question isn't just "Can we integrate this acquisition?" but "Can we integrate this acquisition while managing the three previous ones and preparing for the next two?" Complexity is cumulative, and your internal IT team's capacity is finite.
IT Team Capability and Knowledge Concentration
Objective: Assess whether the target's IT function is a capability you're acquiring or a dependency risk you're inheriting.
What to request:
- IT organisational structure and headcount
- CVs or role summaries for key IT personnel
- Documentation: system admin guides, runbooks, network diagrams, password vaults
- IT service desk or helpdesk ticket history (volume, response times, recurring issues)
Questions to ask:
- Who manages IT day-to-day? Internal team, outsourced MSP, or the owner's nephew?
- Is there a single person who holds all the IT knowledge? What's the retention risk?
- Is there documentation for critical systems, or is it all "tribal knowledge"?
- How is IT support delivered? Formal helpdesk, or ad hoc "tap someone on the shoulder"?
- What's the relationship like between IT and the business? Trusted partner, or constant friction?
Red flags:
- One-person IT department with no documentation or backup
- IT manager planning to leave at or shortly after close
- No documentation for core systems or configurations
- High IT staff turnover or dissatisfaction (signals cultural or capability issues)
- IT function entirely outsourced to an MSP whose contract you don't want to inherit
Retention strategy: If the target's IT person is capable and embedded, make retention a priority. Losing them in the first 90 days turns a manageable integration into a crisis. If they're a knowledge concentration risk, budget for shadowing, documentation, and handover before they leave.
Hidden Costs and Integration Debt
Objective: Uncover the costs and liabilities that don't appear in the P&L or data room but will hit your integration budget.
What to look for:
- Technical debt: Deferred upgrades, unsupported software, infrastructure at end-of-life
- Duplication costs: Paying for duplicate systems during migration (e.g., running old and new CRM in parallel for three months)
- Remediation costs: Security improvements, compliance work, data cleansing
- Change management and training: User adoption support, documentation, helpdesk surge
- Opportunity cost: Internal IT and leadership time diverted from BAU to manage integration
Questions to ask:
- What's been deferred or "kicked down the road" due to budget or capacity constraints?
- Are there any planned IT projects or upgrades that were paused pending the sale?
- What would it cost to bring IT infrastructure and security up to your standard?
- How much will it cost to run duplicate systems during migration?
Red flags:
- Significant deferred maintenance or upgrades
- IT spend significantly below industry benchmarks (indicates under-investment)
- No budget or plan for user training and change management
Real Talk: Integration debt compounds. If you defer integration on acquisition three because you're still finishing acquisition two, you end up with a portfolio of partially integrated businesses running fragmented systems. Eighteen months later, you want to carry out group-wide changes and discover you have no levers to pull. The cost to fix it then is 3–5× what it would have been if you'd integrated properly at the time.
What to Do With Your Pre-Acquisition IT Review Findings
Diligence findings are only valuable if they inform decisions. Here's how to use your IT assessment:
1. Renegotiate deal terms or price if material risks or costs emerge.
If the IT audit uncovers £75K in licencing liabilities, significant cybersecurity remediation, or a core system that needs replacing, that's a valuation adjustment or a seller remediation item. Don't absorb it silently.
2. Build integration cost and timeline into your deal model.
Integration isn't free. If your IT assessment says consolidation will take four months and cost £80K in migration services plus duplicate licences, model it. Include internal resource time, business disruption risk, and contingency.
3. Decide integration approach before you close.
Use the findings to choose High-Touch, Medium-Touch, or Low-Touch integration. Not every acquisition needs full consolidation. If the target's systems are stable and the strategic intent is to leave them semi-autonomous, make that decision explicitly and set boundaries (e.g., integrate finance and security baseline, leave operations separate).
4. Assign accountability and resources for Day 1 and Day 100.
Integration fails when it's everyone's responsibility and no one's. Appoint an integration lead (internal or external), allocate budget and IT resource, and lock in a timeline. At PMI Stack, we act as the execution partner so your internal IT team isn't crushed under integration work while trying to keep BAU running.
5. Communicate findings and risks to stakeholders.
IT risks aren't just IT's problem. If migration will disrupt customer-facing operations for two weeks, Sales and Operations need to know. If there's a cybersecurity remediation requirement, the board and your PE sponsor need visibility. Transparency prevents nasty surprises.
6. Plan for quick wins and visible progress.
Early post-close wins build confidence and momentum. Prioritise integrations that deliver fast value: email and file storage (security and collaboration), financial reporting (CFO visibility), and fixing obvious pain points the acquired team has been complaining about for years. Don't start with the hardest, slowest project.
7. Document the baseline and track integration KPIs.
You can't manage what you don't measure. Capture the "as-is" state during diligence (system inventory, costs, user counts, security posture) so you can track progress and prove value delivery post-close.
Conclusion
Pre-acquisition IT due diligence isn't about finding the perfect target - it's about going in with your eyes open.
Every acquisition brings technical debt. The question is whether you've priced it, planned for it, and resourced it - or whether you'll discover it six weeks post-close when the acquired FD asks why they still can't see consolidated numbers and your IT director is drowning in unplanned migration work.
The roll-ups that execute M&A well treat IT diligence as a core workstream, not an afterthought. They run it early, in parallel with commercial and financial review. They use findings to inform valuation, deal structure, and integration planning. They budget realistic time and cost for integration and assign clear accountability.
The ones that struggle defer IT diligence until the final weeks, treat findings as a compliance checklist rather than decision input, and assume "IT will figure it out" post-close. Then they're surprised when integration drags on for months, costs multiply, and acquired teams lose confidence.
Not luck. Diligence.
If you're facing an acquisition and want a structured IT audit before you sign, we can help. At PMI Stack, we deliver a discovery and audit phase in 2–3 weeks: complete system inventory, integration complexity scoring, risk register, and costed roadmap. Just a clear-eyed view of what you're buying and what it will take to integrate it.
Frequently Asked Questions
When should you conduct IT due diligence in an acquisition?
IT due diligence should run in parallel with commercial and financial workstreams, not after them. Ideally, conduct a high-level pre-LOI scan to surface deal-breakers, then a detailed post-LOI audit to quantify integration costs and complexity before you close the deal.
What are the most common IT due diligence mistakes in mid-market acquisitions?
The biggest mistakes include conducting IT assessment too late in the process, treating it as a siloed technical exercise rather than connecting findings to integration costs, underestimating migration complexity, and ignoring people and process dependencies beyond just the technology assets.
How much can structured IT due diligence reduce post-acquisition integration costs?
Gartner research shows 84% of IT integrations fail or experience significant issues, and 83% of data migrations fail or exceed budget. A structured pre-deal IT assessment surfaces these risks before you sign — when you can still adjust the price, the timeline, or the deal itself that would otherwise emerge after signing.
What is a post-acquisition IT due diligence checklist used for?
A post-acquisition IT due diligence checklist provides a structured framework to evaluate systems, data, infrastructure, vendors, and team capability. It helps quantify integration costs, identify risks, inform valuation adjustments, and create a realistic Day 1 and Day 100 integration roadmap.
What IT red flags should make you walk away from an acquisition?
Deal-breaking red flags include undisclosed data breaches with regulatory liability, business-critical systems that are end-of-life with no migration path, single-person IT dependency with imminent departure risk, material software under-licensing liabilities, and serious GDPR or regulatory non-compliance.
How do you assess data migration risk during IT due diligence?
Assess data quality by requesting sample exports from core systems, checking for duplicates and inconsistencies, verifying GDPR compliance documentation, understanding data storage locations, and evaluating whether customer data is centralised or fragmented across spreadsheets and local drives.
