Key takeaways
- Buyers assess seven dimensions of your IT stack: software inventory, technical debt, system dependencies, security posture, cloud vs. on-premise split, vendor contracts, and IT headcount.
- Undisclosed tech debt does not get waived, buyers price the remediation cost and deduct it from the purchase price.
- Starting technology cleanup 12 months before process gives you time to fix the issues that matter; starting at diligence means discounting them.
In this article
- Why technology diligence is now standard above $10M
- The seven dimensions buyers assess
- Software stack inventory: what to document
- Technical debt: how buyers price it
- System dependencies and single points of failure
- Vendor contracts: change of control provisions
- What to clean up 12 months before process
- Common technology diligence mistakes
- Founder self-assessment checklist: seven dimensions buyers evaluate
- Remediation cost framework
- CTO and tech lead interview preparation
Why technology diligence is now standard above $10M
Five years ago, technology diligence in the lower middle market was episodic, something PE buyers did on software companies, not on services, distribution, or manufacturing businesses. That has changed. Today, technology diligence is standard on virtually every transaction above $10M, regardless of industry.
The reason is straightforward: every business runs on software, and software creates risk, risk of operational disruption post-close, risk of undisclosed cost, and risk of integration complexity that affects the buyer's ability to execute their value creation thesis. A private equity buyer acquiring a $30M EBITDA manufacturing company wants to know if the ERP is NetSuite (modern, cloud, standard integrations) or a 20-year-old on-premise system with no support contract (expensive to replace, risky to maintain, uncertain to migrate).
68% of middle market acquirers reported discovering undisclosed technology issues during diligence that affected purchase price or deal structure. The average purchase price impact was $800K–$2.5M.
Technology diligence is not just a PE phenomenon. Strategic buyers, including competitors, adjacent-market acquirers, and family offices, now include technology questions as a standard component of their diligence process. If you are planning a transaction, assume your buyer will conduct a technology review. Prepare accordingly.
The seven dimensions buyers assess
Technology diligence in the middle market typically covers seven areas. Understanding what buyers assess in each area lets you prepare systematically rather than reactively.
Technology Diligence Assessment Framework
$800K–$2.5M
average purchase price impact of undisclosed technology issues in middle market transactions
12 months
recommended preparation lead time before starting a sale process
$50K–$200K
typical cost of a third-party technology diligence engagement by the buyer
Software stack inventory: what to document
Most middle market companies do not have a complete software inventory. This is not unusual, and it is the norm. The problem is that buyers will build one during diligence, and if it surfaces unexpected costs or compliance issues, the discovery creates friction.
A complete software inventory should document: every application in use (including department-level tools that IT does not centrally manage), license type and count, renewal date, annual cost, and primary user or owner. Tools like Zylo, Torii, or Productiv can automate this inventory for companies with larger stacks. For most middle market companies, a spreadsheet built by walking department by department is sufficient.
The inventory should also flag: unlicensed software in use (common with Adobe Creative Suite, Microsoft Office, and specialty tools), tools with usage below 50% of licensed seats (a waste metric buyers will flag), and tools where the license is in the founder's personal name rather than the company (a clean-up item before close).
The average mid-market company pays for 30–40% more SaaS licenses than are actively used. Buyers treat unused license cost as a normalization item, reducing the implied recurring cost base, which can affect both EBITDA and valuation multiples.
Unlicensed software is not a minor issue. If diligence surfaces Adobe Acrobat, Autodesk, or Microsoft Office installations without valid licenses, buyers treat it as a disclosure failure and a remediation cost. License compliance audits cost $5K–$20K but eliminate a diligence risk that can cost multiples more in purchase price adjustment.
Working through this yourself?
Kolton works directly with founders on M&A readiness, deal structure, and AI implementation — one advisor, not a team of generalists.
Schedule a conversation →Technical debt: how buyers price it
Technical debt is the accumulated cost of shortcuts taken in building or maintaining technology systems, undocumented code, customizations that require manual maintenance, integrations built on workarounds, and software running on versions that are no longer supported.
Buyers price technical debt as a remediation cost. If your ERP has a custom integration that only the outgoing IT manager understands, the buyer estimates the cost to document and stabilize it. If your CRM runs on an unsupported version, the buyer estimates the upgrade cost. Those estimates are deducted from the purchase price or held in escrow as a remediation reserve.
The most common technical debt items in middle market companies: legacy ERP systems (especially on-premise Microsoft Dynamics GP, Sage 50, or older QuickBooks Enterprise at scale); manual data transfers between systems that should be automated; spreadsheet-based processes that substitute for system functionality; custom code with no documentation; and software running on versions with no active vendor support.
Illustrative example, a $45M services company running a 12-year-old on-premise ERP had no active support contract and no documentation of the 8 custom integrations connecting it to their billing and HR systems. During diligence, the buyer's technology firm estimated $350K–$500K to migrate to a modern cloud ERP. The parties agreed on a $400K purchase price reduction. The seller had not anticipated any tech-related adjustment.
Step 1: Inventory all systems, document every application, version, and support status
Step 2: Flag unsupported versions, identify software running on versions with no active vendor support
Step 3: Document integrations, create a data flow map showing how systems connect and where manual transfers occur
Step 4: Assess custom code, identify any custom development, document what it does and who maintains it
Step 5: Estimate remediation cost, get a third-party estimate for the cost to address each identified item
Step 6: Fix or disclose, address high-impact items before process; be prepared to disclose and quantify the rest
System dependencies and single points of failure
Buyers assess what happens when a system goes down. Not because they expect failures, but because undocumented dependencies create operational risk in the 6–18 months post-close when the buyer is integrating and the original IT knowledge is walking out the door.
A dependency map documents: which systems feed which other systems, where data flows are automated vs. manual, what happens operationally if each system is unavailable for 24 hours, and who holds the institutional knowledge for each critical system.
The single-person dependency is the highest-risk item in this category. If your IT manager is the only person who knows how to restore the ERP from backup, run the month-end close process, or manage the CRM integration, that person is a key person risk, not just operationally, but from a transaction structure perspective. Buyers address key person IT risk with retention agreements, escrow, or price adjustments.
Single-person IT knowledge dependency is cited in 52% of middle market transactions as a material integration risk. Buyers typically require either a retention agreement for the key person or documentation sufficient for a replacement to manage the system within 30 days.
The documentation test: could a competent IT professional with no prior knowledge of your business manage your critical systems from your existing documentation alone? If the answer is no, you have an undisclosed dependency risk. Address it before process by documenting each critical system's administration, backup, and recovery procedures.
Vendor contracts: change of control provisions
Every SaaS agreement in your software stack has terms that govern what happens at a change of control. Most founders have never read those terms. Buyers read them during diligence, and unfavorable terms affect deal structure.
Change of control provisions in SaaS agreements can: require vendor consent before the agreement can be assigned to the buyer; give the vendor the right to terminate the agreement on change of control; allow the vendor to reprice on change of control to a higher tier; or simply transfer automatically with no disruption.
The most operationally critical systems — ERP, CRM, billing, payroll, which are the ones where change of control issues create the most risk. If your ERP vendor can terminate your agreement on change of control, the buyer faces an uncertain cost to replace or renegotiate it mid-integration.
Prepare by reviewing the top 10–15 vendor contracts by annual spend and flagging the change of control language. Most vendors will consent to assignment without renegotiation if asked in advance, the friction arises when buyers discover the issue during diligence and the vendor realizes they have leverage.
Top 10–15
vendor contracts to review for change of control provisions before starting a sale process
30–60 days
typical vendor response time for change of control consent if requested proactively
3x–5x
typical increase in negotiation difficulty when change of control issues are discovered during diligence vs
What to clean up 12 months before process
Technology cleanup is most valuable when done 12 months before a sale process starts. At 12 months, you have time to fix issues, demonstrate stability, and include the clean state in the trailing financials that buyers will see. At diligence, you can only disclose and discount.
The highest-priority cleanup items in order of impact: (1) get a software license compliance certificate, resolve all unlicensed software; (2) complete a software inventory and eliminate shadow IT; (3) document the top 10 systems, administration, backup, recovery, key contacts; (4) review change of control provisions in critical vendor agreements; (5) upgrade or plan for replacement of any software on unsupported versions; (6) eliminate manual data transfers that create operational risk; (7) consolidate IT management, reduce key person dependency.
The cost of proactive cleanup is typically $25K–$75K depending on the complexity of the stack. The cost of addressing the same issues as a purchase price adjustment is typically $200K–$750K or more, because buyers apply a risk premium to issues they discover rather than issues that are disclosed and addressed.
Common technology diligence mistakes
No software inventory going into diligence. Buyers build one, and it takes longer, costs more, and surfaces surprises that would not exist with proactive documentation.
Unlicensed software that was never addressed. Adobe, Autodesk, and Microsoft are the most common culprits. Buyers treat unlicensed software as both a remediation cost and a disclosure failure, both have purchase price implications.
No documentation of integrations. Every undocumented integration is a dependency risk in the buyer's model. If the buyer's technology firm cannot map how data flows through the business from existing documentation, they price the mapping cost as a remediation item.
Letting the IT manager be the entire IT function. If one person holds all system knowledge and that person is not staying post-close, the buyer is acquiring an operational black box. Address key person IT dependency before process, either by documenting everything or by retaining the person.
Ignoring change of control provisions until diligence. The vendor who discovers their leverage during diligence is a very different counterparty than the vendor who receives a proactive consent request with 12 months of lead time.
Technology integration is cited as the #1 source of post-close value destruction in middle market transactions, and 60% of technology integration failures trace back to issues that were identifiable, but undisclosed, during diligence.
Founder self-assessment checklist: seven dimensions buyers evaluate
Before engaging a buyer's technology diligence team, founders should complete a structured self-assessment across the seven dimensions buyers will evaluate. This assessment identifies gaps early enough to address them before a process begins.
Technology Self-Assessment: Seven Dimensions
Scroll to see more →
For each red flag identified in this self-assessment, the question is not whether to disclose it, buyers will find it regardless, but whether to address it before a process or disclose and quantify it. Issues addressed before a process are priced as solved. Issues discovered during diligence are priced with a risk premium. The self-assessment is the triage tool that helps founders prioritize which gaps to close versus which to disclose.
Remediation cost framework
When gaps are identified in the self-assessment, the next step is estimating the cost to remediate them. Buyers will produce their own estimates during diligence, having your own estimate in advance allows you to frame the conversation rather than react to the buyer's number.
Remediation Cost Framework
Total pre-sale tech readiness budget: $50K–$500K depending on starting point. For a business with modern cloud infrastructure, good license compliance, and documented integrations, the budget may be $50K–$100K focused on cybersecurity uplift and documentation. For a business with aging on-premise infrastructure, unlicensed software, and no documentation, the full remediation could approach $400K–$500K.
The economics of remediation versus disclosure: a $150K cloud migration that removes a buyer's concern about on-premise infrastructure risk typically prevents a $300K–$500K purchase price adjustment. The buyer's adjustment is not just the cost of the fix, and it includes a risk premium for uncertainty and a buffer for implementation overruns. Investing in remediation almost always produces a better economic outcome than disclosing and negotiating a price adjustment during exclusivity.
Prioritize remediation in this order: (1) license compliance issues (highest visibility, lowest cost to fix); (2) cybersecurity gaps (MFA enforcement is near-zero cost and eliminates a significant diligence flag); (3) documentation (moderate cost, high diligence signal value); (4) technical debt (address highest-risk items; disclose and quantify the rest); (5) infrastructure migration (highest cost, do only if the current state creates a material price adjustment risk).
CTO and tech lead interview preparation
In transactions where there is a CTO, VP Engineering, or technical lead, buyers will interview that person directly. These interviews are designed to assess technical risk independent of what the founder has disclosed. Preparing your technical leader for five predictable questions is one of the highest-return pre-process activities.
Question 1: What would you rebuild if you started today?
Buyers ask this to surface hidden technical debt and the leader's self-awareness about the technology's limitations. A good answer acknowledges specific areas for improvement with a rational explanation for the current state, not a defense of legacy decisions. Prepare your tech lead to answer honestly and contextually: 'We would move to microservices architecture for the billing module, which currently runs on a monolithic codebase that creates deployment friction. We have a 12-month roadmap to address this.'
Question 2: What are your biggest technical risks?
This is a direct risk disclosure question. The worst answer is 'We don't have significant risks', and it signals either dishonesty or lack of awareness. A prepared answer identifies the top two or three risks and explains the mitigation. 'Our primary technical risk is our ERP, which runs on a version approaching end-of-support. We have a migration project scoped for Q3.'
Question 3: How does your tech stack compare to competitors?
Buyers want to know whether the technology is a competitive asset or a liability. A prepared answer maps the core systems to industry standard ('We use Salesforce for CRM, NetSuite for ERP, and AWS for infrastructure, consistent with how most of our competitors are built') and acknowledges any differentiated technology.
Question 4: What is your engineering roadmap for the next 18 months?
This question evaluates whether there is a technology strategy or just maintenance. A prepared answer covers planned investments, their business rationale, and the resource requirements.
Question 5: What happens to the technology if you left tomorrow?
This is the key-person dependency question for technology. The honest answer should describe documentation completeness, team depth, and what a successor would need. If the honest answer is 'It would be very difficult,' that is a preparation item, either document more thoroughly or ensure the tech lead is being retained post-close.
Preparing your technical leader for these questions does not mean scripting dishonest answers. It means ensuring they can answer honestly, confidently, and with context that frames issues appropriately. A technical leader who stumbles on any of these questions signals to buyers that either the technical risks are larger than disclosed or that leadership depth is shallower than presented.
Frequently asked questions
What if we cannot afford to fix all the tech debt before process?
Prioritize disclosure over concealment. Buyers who discover undisclosed tech debt during diligence discount for the unknown, their imagination of the full extent of the problem. Buyers who receive a clean disclosure with estimated remediation costs can price it precisely. Precise pricing is almost always a smaller adjustment than risk-premium pricing.
What does a technology diligence data room look like?
A technology diligence data room typically includes: software inventory with license status and renewal dates; system architecture diagram; vendor contracts for top 10–15 SaaS agreements; IT headcount and org chart; any prior technology assessments; security policies; and incident history.
How is technology diligence different from cybersecurity diligence?
Technology diligence covers the full IT stack, systems, costs, debt, contracts, dependencies. Cybersecurity diligence is a subset focused specifically on security posture, access controls, incident history, SOC 2 status, penetration test results. Many buyers conduct both as separate workstreams.
What technology makes a company more attractive to buyers?
Modern cloud ERP (NetSuite, Sage Intacct), CRM with clean data (Salesforce, HubSpot), documented integrations, and no significant technical debt. Buyers pay a premium for businesses where technology is an asset rather than a liability.
Research sources
Disclaimer: Financial figures and case studies in this article are illustrative, based on representative middle market assumptions, and are not guarantees of outcome. Statistical references are drawn from cited third-party research; individual transaction and operational results vary based on business characteristics, market conditions, and deal structure. This content is for informational purposes only and does not constitute legal, financial, or investment advice. Consult qualified advisors for guidance specific to your situation.
Explore adjacent topics
