The Infrastructure Questions No One Asks Before an Acquisition

By the time attorneys are drafting a purchase agreement and accountants are reconciling three years of financials, the technology environment an acquiring company is about to inherit has usually gone almost unexamined. Financial and legal due diligence are standard practice in nearly every deal. Infrastructure due diligence, the kind that actually opens up a target's systems and asks what's running, who depends on it, and what breaks on day one, is frequently skipped entirely or reduced to a single checkbox nobody follows up on.

Why Infrastructure Gets Skipped in Most Deals

Mid-market transactions typically run on a 60 to 90 day diligence window, and infrastructure is the workstream most likely to get compressed when that clock runs short. Legal counsel works from a fixed list of contracts to review. Accountants work from a fixed list of statements to reconcile. IT infrastructure doesn't have an equivalent standard checklist at most firms, so it gets whatever attention the deal team happens to think to give it, which in practice is often a request for an org chart and a list of major vendors.

That gap has gotten more expensive to leave open. Recent audits of technology-heavy acquisitions found unpatched vulnerabilities present in 97 percent of target codebases and open-source license conflicts in 94 percent, both meaningfully higher than similar audits found two years earlier. Technology integration problems are now a contributing factor in roughly 30 percent of mergers that fail to deliver their expected value, and remediating technical debt discovered after close typically costs 3 to 5 times more than fixing the same issue before the deal signs.

None of this means infrastructure due diligence has to become exhaustive or slow the deal down. It means the questions asked need to go further than whether the systems work today, because a system that works fine on the day of the letter of intent can still be running on a vendor relationship, a license structure, or a single employee's institutional knowledge that doesn't survive a change of ownership.

Part of the reason infrastructure gets shortchanged is who ends up responsible for reviewing it. A recent survey of corporate dealmakers found that technology review has become the most burdensome and expensive element of the entire due diligence process for a majority of respondents, yet infrastructure specifically is still commonly delegated to whichever advisor has spare capacity on the deal team rather than to someone with real operational IT background. Legal and finance advisors are good at their own workstreams. Reading a Kubernetes architecture diagram or a cloud spend report isn't one of them, and it usually shouldn't be.

The Blind Spots Standard Due Diligence Misses

Vendor contracts and what triggers on change of control. Roughly 85 percent of enterprise software and SaaS agreements include some form of change-of-control provision, and most require the vendor's prior written consent before the contract carries over to a new owner. In due diligence reviews of technology-dependent companies, change-of-control consent requirements turn up as a material risk factor 60 to 70 percent of the time, because a single vendor withholding consent, or using it as leverage to renegotiate pricing, can hold up post-close integration or quietly increase the cost of ownership. Legal counsel typically flags these clauses if they read every contract, but they rarely have the context to know which vendor relationships are actually load-bearing for day-to-day operations versus which ones are incidental.

The real inventory of systems, not the official one. Every company has an approved list of software. Almost none of them has an accurate one. Zylo's research on shadow IT has documented cases where a single department accumulated dozens of unauthorized SaaS subscriptions over a year or two, adding real ongoing cost that never showed up in an official technology budget. When that inventory surfaces after close instead of before it, remediation, meaning identifying what each tool does, who depends on it, and whether it can be consolidated or needs to be replaced, commonly takes 30 to 90 days and delays the integration timeline the deal model was built around.

Technical debt with a due date. Every infrastructure environment carries some technical debt. The question that matters in a deal isn't whether debt exists, it's when it comes due. A server refresh cycle that was already overdue, a compliance certification that expires within a year of close, or a custom integration built by a contractor who's no longer reachable are all liabilities with a specific timeline attached, and that timeline needs to factor into deal pricing the same way a lease obligation or a warranty liability would.

Key-person risk inside IT. Financial due diligence routinely asks about key-person risk on the executive team. It rarely asks the same question about whoever holds the institutional knowledge for how the target's systems actually fit together. In smaller companies, that knowledge often lives with one or two people, and if a retention plan isn't part of the deal structure, an acquirer can end up owning infrastructure nobody left standing can fully explain.

Cloud commitments sized for the wrong trajectory. Multi-year reserved-capacity contracts and volume-discount tiers are usually negotiated based on where a company expected to be, not where it actually ended up. An acquirer inherits whatever commitment structure is in place, and if the target's growth stalled or accelerated differently than projected, that contract can turn into either wasted spend the new owner is locked into or a capacity ceiling that gets hit sooner than expected post-close. Unpredictable cloud costs are consistently one of the risks that surfaces only after a deal closes, precisely because reviewing a cloud bill takes a different kind of scrutiny than reviewing a balance sheet.

A Framework for Asking the Right Infrastructure Questions Before You Sign

Who owns each material vendor contract, and what happens to it on change of control? Pull the actual assignment and consent language, not a summary of it, for every vendor that supports a core business function.
What's the complete inventory of systems and subscriptions, including the ones IT didn't approve? A department-by-department spend review usually surfaces more than the official technology budget does.
What technical debt exists, and on what timeline does each item come due? Rank it by dollar exposure and deadline, not just by severity.
How does the security posture measure up against a recognized framework, not just against "nothing's happened so far"? The NIST Cybersecurity Supply Chain Risk Management due diligence guide is a useful, vendor-neutral starting point for structuring this review.
What's the actual state of backups and disaster recovery, confirmed by a test rather than a policy document? A written recovery plan that's never been tested is not the same thing as a working one.
Where do the two companies' architectures genuinely conflict, and where do they just look different on paper? Overlapping tools aren't automatically a problem; incompatible data models and authentication systems usually are.
Who holds the institutional knowledge that keeps this environment running, and what's the retention plan for them? If the answer is one person, that's a finding, not a footnote.
What would it realistically cost and how long would it realistically take to integrate, separate, or replace these systems? Build this estimate from the actual inventory above, not from a rule-of-thumb percentage of deal value.

What These Questions Are Worth When They Get Asked

The financial upside of asking is measurable. Deals where buyers surfaced material technology findings, whether in code quality, cybersecurity exposure, or licensing, get re-traded 30 to 40 percent of the time, with price reductions typically running 5 to 25 percent once those findings are on the table. That's not diligence slowing a deal down. That's diligence doing what it's supposed to do: making sure the price matches what's actually being purchased.

Diligence Area	Common Assumption	What a Real Review Often Finds
Vendor contracts	"Contracts transfer automatically"	Consent required in most agreements
Software inventory	"IT has the full list"	Unapproved tools running real workflows
Technical debt	"Nothing urgent is pending"	Deadlines tied to certifications or hardware
Security posture	"No incidents means we're fine"	Gaps against a recognized framework
Key-person dependency	"The team will stay through the transition"	No documented retention plan

How This Fits Alongside Deal Counsel and Existing IT Support

Infrastructure due diligence isn't a substitute for legal or financial diligence, and it isn't a replacement for the managed service provider running either company's day-to-day IT operations. An MSP keeps servers patched and help desk tickets resolved; that function doesn't stop during a transaction and shouldn't be expected to also produce an independent technology risk assessment on top of its regular workload. Elevaire Systems steps in specifically to run the infrastructure lens of diligence, working alongside deal counsel and the existing IT team rather than around them, and handing the deal team a clear, dollar-and-timeline-specific picture of what's actually being acquired before the purchase agreement is final.

That engagement typically produces three concrete deliverables: a full systems and vendor inventory with change-of-control exposure flagged contract by contract, a technical debt and security gap list ranked by dollar exposure and deadline, and an integration cost and timeline estimate the deal team can actually hold financing or price negotiations against. None of it requires displacing the advisors already on the deal. It requires someone whose full-time focus during the diligence window is the infrastructure question nobody else on the team is positioned to answer.

Frequently Asked Questions

How much does infrastructure due diligence typically cost?

It scales with the complexity of the target's environment rather than deal size alone. A company running a handful of core systems on a single cloud platform is a much faster, less expensive review than one with multiple legacy systems, several data centers, or a history of acquisitions of its own. The cost is almost always small relative to the price adjustments or post-close remediation it can help avoid.

How does this work alongside our existing MSP or internal IT team?

It's additive, not a replacement. The MSP or internal team supporting either company continues running day-to-day operations throughout the transaction. Infrastructure due diligence is a separate, time-boxed engagement focused specifically on assessing what's being acquired, and the findings get handed back to the deal team and the existing IT function rather than displacing either one.

How long does an infrastructure due diligence review actually take?

For a company in the 25 to 200 employee range, a focused review typically fits inside a two to four week window, which aligns with the infrastructure workstream of a standard 60 to 90 day mid-market deal timeline rather than extending it.

What happens if the review turns up major issues after a letter of intent is already signed?

That's a normal outcome, not a failed process. Findings surfaced during diligence typically feed into price negotiation, specific closing conditions, or a post-close remediation plan with an agreed timeline and budget. The goal is making sure those issues are known and priced in before close, not stopping a deal that still makes sense.

How do we get started if we have a deal in progress right now?

The earlier an infrastructure review starts relative to the closing date, the more its findings can actually influence price and deal terms rather than just informing a post-close to-do list. Reach out with the target's basic technology profile and the current deal timeline, and the scope of review can be sized to fit the diligence window already in place.