Technology due diligence: an IT checklist for business acquisitions

Why technology due diligence matters

Most acquirers spend considerable time on financial, legal and commercial due diligence. Technology tends to receive a lighter touch – a few questions in the information request, a conversation with the IT manager, a tick in a box. That's a mistake with real financial consequences.

Technology underpins almost every operational process in a modern business. When systems are poorly maintained, integrations are fragile or compliance obligations haven't been met, the remediation cost falls on the new owner. In some transactions, that cost is manageable. In others, it's enough to fundamentally change the economics of the deal.

The goal of technology due diligence isn't to find reasons to walk away. It's to give the buyer an accurate picture of what they're acquiring – so they can price it correctly, plan the integration properly and avoid being surprised on Day 1 by something that should have been visible before signing.

What technology due diligence covers

A thorough technology DD exercise covers six interconnected areas:

• Infrastructure – physical and cloud infrastructure, networks, servers, telephony and connectivity
• Applications and software – ERP, CRM, bespoke systems, SaaS subscriptions and the dependencies between them
• Data – what data is held, where it lives, how it's protected and whether it's processed in compliance with GDPR
• Security – the overall security posture, known vulnerabilities and any historical incidents
• People – IT team structure, key-person dependencies and contractor or supplier relationships
• Contracts – software licences, support agreements, SaaS renewals and IT service contracts

The depth of review in each area will vary with the size and complexity of the transaction. A small bolt-on acquisition doesn't need the same scrutiny as a platform deal. What matters is that all six areas receive at least some structured attention.

IT infrastructure assessment

The infrastructure review establishes the physical and logical foundation on which the business runs. Key questions to answer:

• Is the infrastructure cloud-based, on-premise or a hybrid? Is that appropriate for the business's size and operational profile?
• Are there end-of-life systems – servers, networking equipment or operating systems – that are no longer receiving security updates?
• What are the maintenance and renewal obligations, and when do they fall due? Are any significant capital expenditures imminent?
• Is the infrastructure documented? Can someone other than the person who built it understand how it works?
• What are the disaster recovery and business continuity provisions? Have they been tested?

Infrastructure surprises after acquisition are common. An ageing server estate, a hosted data centre contract with onerous exit terms, or a cloud environment that's been provisioned without any cost governance – these findings affect both the integration timeline and the post-acquisition cost base.

Core systems and software evaluation

This section of the review looks at the applications the business runs on: what they are, how they're licenced and how deeply embedded they are in day-to-day operations.

Standard commercial products – a well-known ERP, an off-the-shelf CRM – are generally lower risk. They have vendor support, documented upgrade paths and a market of people who understand them. Bespoke systems are a different matter. Code that was built in-house, or commissioned from a developer who may no longer be available, carries concentrated risk – particularly if it's undocumented.

The questions to ask of every significant system:

• What is the licence model and annual cost? Does the licence transfer on acquisition, or does it need to be renegotiated?
• Are there integration dependencies – data feeds between systems, API connections – that would be complex or disruptive to change?
• What is the vendor's roadmap for the product? Is the system heading towards end-of-life?
• Is the system under active support? Are updates applied regularly?

SaaS subscriptions deserve specific attention. Businesses accumulate them quickly and rationalise them rarely. An audit of active subscriptions frequently reveals duplication, unused licences and tools that have been embedded in workflows but whose contracts haven't been reviewed in years.

Security posture and vulnerability assessment

The security review assesses how well the business protects its systems and data against threats. The appropriate depth of review scales with transaction size: a document and configuration review for smaller deals, full penetration testing for larger ones.

Certain findings should be escalated immediately, regardless of transaction size:

• Known, unpatched critical vulnerabilities on internet-facing systems
• No multi-factor authentication on critical systems, email or remote access
• No evidence of backup testing – having a backup process is meaningless if restores haven't been verified
• No incident response process – no plan for what happens when something goes wrong
• Historical data breaches that weren't disclosed in the information request

A business that hasn't invested in basic security hygiene is a liability exposure, not just an operational risk. Post-acquisition, that exposure transfers. If a breach occurs in the months after completion, and it relates to a vulnerability that existed before the transaction, the reputational and regulatory consequences sit with the new owner.

Technical debt: identifying and quantifying it

Technical debt is the accumulated cost of shortcuts, deferred maintenance and pragmatic decisions made under time pressure that were never revisited. It includes outdated code, legacy integrations built to solve an immediate problem, undocumented systems and infrastructure that hasn't kept pace with business growth.

Quantifying technical debt is genuinely difficult. There's no line on a balance sheet. But the indicators are recognisable:

• Systems that key people are reluctant to modify for fear of breaking something else
• Integrations that "just work" – and that nobody in the business fully understands
• Documentation that doesn't exist, is out of date or describes how systems were supposed to work rather than how they actually work
• A pattern of workarounds: spreadsheets sitting alongside systems that should be handling the same data, manual steps that should have been automated

Technical debt isn't necessarily a deal-breaker. Every business carries some. The issue is when it's unacknowledged, when the cost of addressing it hasn't been factored into the acquisition model, or when it's so deeply embedded that it constrains what the acquiring business can do with the target post-completion.

IT team and supplier assessment

Systems are only as stable as the people who manage them. The team assessment looks at who owns the technology function, how that capability is structured and where the risks lie.

Key-person dependency is one of the most common findings in technology due diligence at the SME level. If one person leaving would create a significant operational technology risk – because they're the only one who understands a bespoke system, holds the admin credentials or manages the critical vendor relationships – that's a risk factor that needs to be addressed in the transaction structure, not discovered after completion.

Assess the following:

• Who has knowledge of how the bespoke or custom systems work? Is that knowledge documented anywhere?
• Who manages the key supplier and vendor relationships? Are those relationships personal or institutional?
• Who holds the admin credentials for critical systems? Are those stored securely and accessibly?
• What is the structure of the IT function – internal team, outsourced MSP or a mix? Are the support contracts transferable?

Supplier contracts also need review. IT service agreements often contain change-of-control clauses that can affect pricing, termination rights or continuity of service. Finding out about these after completion limits your options considerably.

Integration and transition planning

The final – and frequently underestimated – part of technology due diligence is thinking through what integration will actually require.

Connecting two ERP systems takes longer than anyone expects. Migrating to shared infrastructure disrupts operations. Rationalising overlapping SaaS stacks requires decisions about which tools to retire and which to standardise on, followed by the work of migrating data and retraining people. Each of these workstreams carries operational risk, requires dedicated resource and takes time away from running the business.

Technology DD should inform the integration plan, not just the transaction model. Specifically:

• Which systems will be retained, rationalised or replaced post-acquisition?
• What are the data migration requirements, and what are the dependencies?
• Are there contractual constraints – licence terms, support agreements – that affect the integration sequence?
• What resource will integration require, and is that available internally or does it need to be brought in?

A realistic integration assessment, built on accurate findings from the DD process, is the difference between a transition that proceeds to plan and one that consumes management attention and budget for longer than it should.