Here is how technology due diligence works on most acquisitions. Someone from the deal team (usually a financial analyst or a junior associate) schedules a call with the target company's IT manager. They ask a version of "is everything working?" The IT manager, who wants to keep their job post-acquisition, says yes. A few follow-up questions about server locations and backup frequency. A paragraph in the deal memo. Box checked.
Three months after close, the acquiring company discovers that the target's core ERP system is running on an unsupported version, their Microsoft licensing is short by forty seats, the "backup system" hasn't been tested in two years, and the one person who understands the production database left during the transition. These aren't hypothetical scenarios. These are the patterns that repeat across acquisitions of all sizes, in every sector, with depressing regularity.
The financial diligence gets weeks of senior attention. The legal diligence gets weeks of senior attention. The technology diligence gets an afternoon. And then the integration budget overruns by a factor of three, and everyone acts surprised.
PE firms are getting better at this. The sophisticated ones now include technology diligence as a standard workstream alongside financial, legal, commercial, and operational. But even among PE-backed acquisitions, the depth and quality of the technology assessment varies enormously. And for trade acquisitions (where one operating company is acquiring another) technology diligence is still frequently treated as an afterthought.
What technology due diligence should actually cover
Proper technology due diligence is a structured assessment of seven distinct areas. Each one has the potential to surface liabilities that affect the deal price, the integration timeline, or the viability of the acquisition itself. Skip any of them and you're guessing.
Infrastructure assessment
Start with the physical and virtual infrastructure. Not "do they have servers?" but a detailed inventory: make, model, age, warranty status, capacity utilization, and end-of-life dates. The same for network equipment. Switches, firewalls, wireless access points, WAN links. Every piece of it.
What you're looking for is deferred capital expenditure. A company that's been running lean ahead of an exit will have postponed hardware refreshes. That three-year-old SAN with no warranty? It's now your problem. Those end-of-life Cisco Catalyst switches running IOS versions with known CVEs? Also your problem. The aging UPS that hasn't had a battery replacement in four years? That's a single point of failure for every system in the building, and it's going to fail at the worst possible moment.
Cloud infrastructure needs the same scrutiny. An AWS or Azure environment that's been growing organically for five years will have orphaned resources, oversized instances, unused reserved capacity, and services that nobody remembers deploying. The monthly cloud bill might look reasonable at the headline level, but dig into the details and you'll find waste, security risks, and architectural decisions that made sense three years ago but are now technical debt.
We build a complete asset register with replacement cost estimates and timeline urgency. Everything gets categorized: functional and current, functional but aging, end-of-life and needs immediate replacement. The total replacement cost for the "immediate" category alone has shifted deal valuations significantly. Or at least forced a renegotiation of the purchase price to account for near-term capital requirements the seller hadn't disclosed.
Software licensing audit
Licensing compliance is where acquisitions quietly hemorrhage money. The target says they have 200 Microsoft 365 licenses. The actual headcount using Microsoft 365 is 260. That's a compliance gap, and when Microsoft audits (which they will, because acquisitions trigger audit clauses in most enterprise agreements) the acquiring company is liable for back-licensing, penalties, and a renegotiated agreement at current list prices.
This isn't limited to Microsoft. Oracle is notorious for aggressive license auditing post-acquisition. Their License Management Services team monitors public deal announcements and will contact the acquiring company within months of close. Oracle's definition of "named user" and "processor" licensing is intentionally complex, and most organizations are inadvertently non-compliant in ways that only become visible under formal audit. The remediation costs can be staggering.
VMware licensing changed dramatically after the Broadcom acquisition, and companies that were compliant under the old per-socket model suddenly weren't under the new per-core subscription model. SAP has complex indirect access rules that most organizations don't fully understand (if a third-party system reads or writes SAP data, even through a middleware layer, SAP may consider that an indirect access that requires licensing. Adobe Creative Cloud, Autodesk, specialized engineering software) all of it needs a seat-by-seat reconciliation against actual deployment.
The question isn't "do they have licenses?" It's "are they compliant, and what is the true cost of making them compliant under the acquiring company's enterprise agreements?" Those are very different questions, and the difference between the answers can represent a material liability.
Run a software asset management scan. Use tools like Snow Software, Flexera, or even the built-in Microsoft assessment tools. Cross-reference what's installed against what's licensed. Flag every discrepancy. Then price the remediation under the acquiring company's licensing structure, not the target's, because the target's volume discounts and enterprise agreements may not transfer.
Security posture
A proper security assessment during due diligence covers four dimensions: technical controls, policies and procedures, incident history, and compliance status.
Technical controls means vulnerability scanning at minimum, and ideally a focused penetration test against internet-facing assets. You need to know what's exposed, what's unpatched, and what an attacker could reach from the outside. Pre-acquisition penetration tests routinely find default credentials on internet-facing administrative interfaces, unpatched VPN concentrators with known remote code execution vulnerabilities (the Fortinet FortiOS and Pulse Secure/Ivanti vulnerabilities of recent years are still found in production environments with alarming frequency), and web applications with injection flaws that would take a competent attacker minutes to exploit. These aren't theoretical risks. They're open doors.
Policies and procedures means reviewing their information security policy, acceptable use policy, incident response plan, and business continuity plan. Not just confirming these documents exist (plenty of organizations have policies that were written five years ago and never updated) but assessing whether they're implemented, tested, and followed. Ask for evidence of the last incident response drill. Ask for the last penetration test report and the remediation actions taken. If the answers are vague, that's your answer.
Incident history is revealing. Ask for their security incident log. If they don't have one, that's an answer in itself. If they do, look at what happened, how it was detected, how it was responded to, and what changed afterward. A company that's had incidents and learned from them is in a better position than one that claims to have never had an incident. The latter is either lying or not detecting. Given that the average dwell time for a network intrusion is still measured in months, not days, "we've never had an incident" usually means "we've never detected an incident."
Compliance status depends on the sector. PCI DSS for anything touching payment card data. HIPAA for healthcare. SOX for publicly traded companies. ISO 27001 or SOC 2 if they're selling to enterprise clients. GDPR and data protection compliance for any organization handling personal data of EU residents. Non-compliance here isn't just a technical problem; it's a regulatory liability that transfers to the acquirer. And the timeline for achieving compliance post-acquisition, if the target isn't there already, can be measured in months and significant expenditure.
Data architecture and recovery capability
Where is the data? All of it. Production databases, file shares, email archives, application data stores, cloud storage, local drives, removable media. You need a complete data map, because you can't protect or migrate what you can't find.
Then: how is it backed up? What's the backup schedule, the retention period, the storage location? Is there geographic separation between production data and backup data? Are backups encrypted, and who holds the encryption keys? When was the last time a full restore was tested. Not a single file restore, but a full system recovery from bare metal? If the answer is "we haven't tested a full restore," then the backup system is theoretical until proven otherwise. And "theoretical backup" is functionally equivalent to "no backup" when you actually need it.
Disaster recovery is the next layer. Is there a DR plan? Has it been tested? What's the documented Recovery Time Objective and Recovery Point Objective, and are those numbers realistic given the infrastructure? A company that claims a four-hour RTO but has no automated failover, no DR site, and a manual restore process that takes two days is not being honest about their recovery capability. Probably not maliciously, but because nobody has pressure-tested the plan against reality. The gap between documented DR capability and actual DR capability is, in our experience, one of the most consistent findings in technology due diligence.
Data sovereignty matters too. If the target operates across multiple jurisdictions, where is data physically stored? GDPR, CCPA, and sector-specific data residency requirements can all create complications if data is in the wrong place. A SaaS product that stores data in a US data center may violate data residency requirements that apply to the target's European operations. Post-acquisition, the acquiring company inherits those compliance obligations and the remediation costs if the target wasn't meeting them.
Vendor dependency analysis
Every organization has critical vendor relationships. The question is whether anyone has documented them, and whether the terms survive an acquisition.
Pull every technology vendor contract. Map them against criticality: which vendors, if they terminated the relationship tomorrow, would stop the business from operating? For most organizations, that list is shorter than you'd think. Cloud provider, ERP vendor, internet connectivity provider, maybe a specialist software vendor or two. But the contracts governing those relationships matter enormously.
Look for change-of-control clauses. Many enterprise software agreements include provisions that allow the vendor to renegotiate or terminate the agreement upon a change in ownership. If the target's discounted Microsoft Enterprise Agreement has a change-of-control clause, the acquirer may end up paying list price post-close. And the gap between a negotiated EA price and list price can be 30-40%. If the target's data center colocation contract allows termination on change of ownership, the acquirer needs a migration plan before closing, not after.
Renewal dates matter. A contract that renews in three months at a higher rate is a near-term cost that should be in the financial model. A contract that's been on month-to-month for two years because nobody bothered to renegotiate is a risk. The vendor can change terms with 30 days' notice. Aggregate the contract renewal calendar for the full vendor estate and you get a picture of near-term cost commitments that the deal model needs to account for.
The most dangerous vendor dependency is the one nobody thinks of as a vendor dependency. It's the freelance developer who built the custom CRM integration and is the only person with the source code. It's the consultant who configured the ERP system seven years ago and still gets called when it breaks. It's the managed service provider who has the admin credentials to everything and hasn't signed a contract that includes IP assignment or knowledge transfer obligations.
Technical debt assessment
Technical debt is deferred maintenance in software and systems. It accumulates when organizations choose quick fixes over proper solutions, skip documentation, postpone upgrades, or build workarounds instead of addressing root causes. In an acquisition context, technical debt is a hidden liability that's as real as deferred maintenance on a building. It doesn't appear on the balance sheet, but it has a quantifiable cost.
For organizations with custom-developed software (which is most organizations above a certain size, even if they don't think of themselves as software companies), a code quality assessment is essential. How old is the codebase? What languages and frameworks is it built on? Are those frameworks still maintained? Is there documentation? Are there automated tests? How long would it take a new developer to become productive in this codebase? What's the bus factor how many people need to be unavailable before the organization can't maintain or modify the system?
For off-the-shelf systems, the equivalent questions are: how heavily customized is the system? Are those customizations documented? Will they survive a version upgrade? An SAP environment with 500 custom ABAP programs is a fundamentally different proposition from a vanilla installation. A Salesforce org with 200 custom Apex triggers, 50 process builders, and a dozen managed packages has a complexity profile that the license cost alone doesn't reveal.
How many integrations exist between systems, and are they maintained through supported APIs or fragile point-to-point scripts that break when anything changes? We've found integration code running on individual desktops, scheduled as Windows Task Scheduler jobs, with no monitoring, no error handling, and no documentation. When that desktop gets replaced or the user account gets disabled post-acquisition, the integration silently stops and nobody notices until a downstream process fails.
Technical debt doesn't mean the technology is bad. Every organization accumulates it. But the acquirer needs to understand the magnitude and the cost of addressing it, because that cost is real and it's coming. Either as planned remediation or as unplanned incidents.
Integration complexity estimation
The final piece is the hardest to get right, but it's what the deal team actually needs: how complex and expensive will the post-acquisition technology integration be?
This depends on the acquisition strategy. A bolt-on that will operate independently has minimal integration requirements. Maybe just email, identity management, and financial reporting. A full integration into the parent company's technology stack is a different order of magnitude. The acquiring company's IT team needs to absorb the target's users, data, applications, and infrastructure into their own environment, and that process takes months at minimum.
The integration estimate should cover identity and access management (merging Active Directory forests or migrating to a single Entra ID tenant (and AD forest merges are among the most complex and risk-laden operations in enterprise IT), email and collaboration (moving to a single Microsoft 365 tenant, which requires careful planning around shared mailboxes, distribution lists, Teams channels, and SharePoint sites), ERP and financial systems (chart of accounts mapping, data migration, process harmonization), line-of-business applications (keep, replace, or integrate) and each option has cost and risk implications), network infrastructure (site-to-site connectivity, firewall policy harmonization, DNS namespace consolidation), and security (extending the acquiring company's security controls, monitoring, and incident response to the target's environment).
Every one of those workstreams has people, timeline, and cost implications. Getting the estimate wrong (which most deal teams do, because they don't involve the right technical people early enough) means the integration budget is fiction. And fictional budgets have a way of becoming very real overruns.
The 100-day post-close technology plan
Due diligence produces findings. Those findings need to become an actionable plan that starts on day one post-close. The first 100 days are critical because they set the trajectory for the entire integration, and delays in the first 100 days tend to compound throughout the program.
Days 1-14: Secure and stabilize. Get control of the target's technology environment. Ensure administrative credentials are documented and held by the acquiring company's IT leadership. Verify backup systems are functioning. Implement any critical security remediations identified during due diligence. Disable accounts for departed employees. Confirm that change-of-control notifications have been sent to vendors where required. This is housekeeping, but it's essential housekeeping that prevents the kind of access control gaps that create security incidents during transitions.
Days 15-45: Assess and plan. Complete a detailed assessment of any areas that couldn't be fully examined during due diligence (some targets restrict access to production systems pre-close). Finalize the integration plan with specific workstreams, owners, timelines, and budgets. Identify quick wins (license consolidation, contract renegotiation, duplicate system elimination) that can demonstrate early value and build momentum.
Days 45-75: Execute quick wins. Consolidate email if the decision is to move to a single tenant. Rationalize licenses. Remove duplicates, right-size tiers, consolidate under the acquiring company's enterprise agreements. Begin network integration if sites need to communicate. Start decommissioning systems that the integration plan has marked for retirement.
Days 75-100: Measure and adjust. Evaluate progress against the integration plan. Identify workstreams that are behind schedule and understand why. Adjust timelines and resources based on what you've learned in the first 75 days. Report to the deal sponsors on integration status, costs incurred versus budget, and any risks that have materialized or changed in severity.
This timeline assumes a mid-market acquisition with moderate complexity. Larger or more complex deals need a longer horizon and a dedicated integration management office. But the principle is the same: plan before you close, execute immediately after, and measure continuously.
What PE firms and acquirers consistently miss
Even among sophisticated acquirers, certain patterns of oversight repeat.
Shadow IT. Systems and services that the IT department doesn't know about, procured directly by business units with corporate credit cards. Marketing's analytics platform. Sales' CRM add-ons. Engineering's AWS account that someone spun up for a proof of concept three years ago and is now running a production workload. Shadow IT is unmanaged, unpatched, unmonitored, and invisible until you go looking for it. Reviewing credit card and procurement records for technology-related charges usually surfaces it. The cleanup and consolidation cost is real, and it's rarely in the deal model.
The key-person problem. The IT manager who's been there for twelve years and has the entire environment in their head. The network admin who's the only person with the firewall credentials. The DBA who's the only one who understands the production database schema and why that stored procedure runs for six hours every Sunday night. These are not staffing risks. They are operational risks. If any of these people leave during the transition (and transitions are exactly when people leave, because uncertainty drives departures) critical institutional knowledge walks out the door with them.
Key-person risk is the one that bites hardest because it's the most time-sensitive. Hardware can be replaced. Licenses can be brought into compliance. But if the person who knows how the core systems work decides to leave in month two of the integration, and nobody documented their knowledge beforehand, the recovery timeline is measured in months, not days. Consider retention packages for critical technical staff as part of the deal structure, not as an afterthought.
Undocumented systems and integrations. The custom integration that connects the ERP to the warehouse management system, written by a contractor five years ago, running on a virtual machine that nobody touches because nobody understands what it does but everyone knows that when it was accidentally rebooted last year, order processing stopped for a day. These systems are everywhere. They work until they don't, and when they break, there's no documentation, no source code repository, and no one who remembers how they were built.
Expired licenses in production. Not unlicensed software. Software that was properly licensed at one point, but the licenses expired or the subscription lapsed, and nobody noticed because the software kept working. This is particularly common with on-premises software that uses license keys rather than cloud authentication. The software runs fine without an active license until the vendor discovers it and sends an invoice with penalties. Or until the acquirer's compliance audit catches it.
Cyber insurance gaps. The target may have cyber insurance, but does the policy survive the acquisition? Many cyber insurance policies have change-of-control provisions. And even if the policy transfers, the acquiring company's risk profile may differ from the target's, which could affect coverage or premiums. Verify the target's cyber insurance status as part of due diligence, and factor in the cost of extending the acquiring company's policy to cover the target's environment.
Quantifying what you find
The deal team doesn't need a list of technical issues. They need numbers. Every finding needs to be translated into cost and timeline, because those are the inputs that affect the deal model.
This infrastructure needs replacement within six months. Estimated cost and procurement timeline. This licensing gap will cost this amount to resolve, and the remediation window is this long because the vendor's true-up process takes this many weeks. This integration will take this many months and require this many people at this loaded cost. This security remediation is needed before the acquiring company can extend its cyber insurance to cover the target.
Aggregate these into a single figure: the technology adjustment. This is the number that goes back to the deal team as an input to price negotiation. In our experience, the technology adjustment for a typical mid-market acquisition ranges from five to twenty percent of the deal value, depending on the state of the target's technology estate. That's a material number. It's worth getting right.
The organizations that get technology due diligence right don't treat it as a checkbox. They treat it as what it is: a critical input to the investment decision that can protect the deal from turning into an expensive lesson in what happens when you buy a company without understanding what's under the hood.