Tech Due Diligence: What to Check Before Buying a Business


You’re buying a business. The financials look good. The customers seem happy. The operations make sense.

But what about the tech?

Technology can hide expensive surprises. Aging systems about to fail. Licensing time bombs. Integration nightmares waiting to happen.

Here’s what to check before you sign.

The Tech Due Diligence Checklist

1. Complete Software Inventory

Request a list of every software subscription. Not just major ones, everything.

For each:

  • What is it?
  • What does it cost annually?
  • How many users/licenses?
  • What contract terms (especially renewal dates and notice periods)?
  • Who owns the contract (company or individual)?

Why it matters: Hidden subscriptions add up. Contracts that auto-renew at higher rates create surprises. Individual-owned subscriptions might not transfer.

2. Integration Map

How do systems connect?

  • What integrates with what?
  • How? (native, Zapier, custom)
  • Who maintains the integrations?
  • What breaks if one system changes?

Why it matters: Complex integration architectures are fragile. Custom integrations need ongoing maintenance. Post-acquisition, you might want to change systems and integrations constrain that.

3. Critical System Dependencies

Which systems would stop the business if they failed?

  • E-commerce platform (for retailers)
  • CRM (for sales-driven businesses)
  • ERP/accounting (for most businesses)
  • Industry-specific software

For each critical system:

  • How long has it been in place?
  • Who knows how it works?
  • What’s the disaster recovery plan?

Why it matters: Critical systems need to be healthy. Single points of failure are risks.

4. Data Ownership and Portability

  • Is customer data in systems you own or cloud services?
  • Can data be exported?
  • Are there vendor lock-in risks?
  • Do you have access to historical data?

Why it matters: Data is often the most valuable asset. If it’s locked in systems that are hard to leave, that’s a constraint on post-acquisition strategy.

5. Security Assessment

Basic security review:

  • Is MFA enforced on critical systems?
  • When was the last password policy audit?
  • Who has admin access to what?
  • Any recent security incidents?
  • What’s the backup and recovery situation?

Why it matters: Security problems become your problems. Previous breaches might have legal implications. Poor security is expensive to fix.

6. Technical Debt Assessment

For companies with custom software or heavy technical components:

  • When was code last updated?
  • Is documentation current?
  • Are systems on supported versions?
  • What known issues exist?

Why it matters: Technical debt is real cost. Old systems require investment to update or replace.

7. IT Service Relationships

  • Who provides IT support?
  • What’s the contract term and cost?
  • If in-house IT, who are the key people?
  • What knowledge leaves if those people leave?

Why it matters: IT support continuity matters. Key person dependencies are risks.

8. Pending Technology Projects

What’s in progress?

  • Projects currently underway
  • Commitments made but not started
  • Known needs that haven’t been addressed

Why it matters: Pending projects are pending obligations. You’ll inherit them.

9. Customer-Facing Technology

What technology do customers interact with?

  • Website/e-commerce platform
  • Customer portal
  • Mobile apps
  • Integration points with customer systems

Assess the health and quality of each.

Why it matters: Customer-facing tech directly impacts customer experience and retention.

10. Licensing Compliance

  • Are software licenses properly owned and compliant?
  • Any open-source usage with licensing implications?
  • Any pirated or improperly licensed software?

Why it matters: Licensing violations become your liability.

Red Flags

Watch for these in due diligence:

No software inventory exists. If they can’t list their tools, they don’t have control.

Critical systems running on unsupported versions. Old Windows versions, outdated databases, unsupported frameworks.

Single person knows everything. Key person dependency without documentation.

No backups or untested backups. Ask for proof of recent successful backup restore.

Contracts tied to individuals. Software licensed to a person, not the company.

Pending security issues. Especially any unresolved security incidents.

Recent major system failures. Ask about outages in the past year.

How Deep to Go

The depth of tech due diligence depends on:

Size of acquisition. Larger deals warrant more investigation.

Tech intensity of the business. A software company needs deeper tech DD than a restaurant.

Your technical capacity. Do you have expertise to assess or need external help?

For small acquisitions of non-tech businesses, the checklist above can be self-administered.

For larger acquisitions or technology companies, bring in expertise. Consultants who specialize in tech due diligence exist.

Post-Acquisition Planning

Due diligence isn’t just about finding problems. It’s about planning for post-acquisition.

Based on what you find:

Integration plan. How will acquired systems work with your existing systems?

Consolidation opportunities. Where can you combine tools and reduce costs?

Upgrade timeline. What aging systems need attention and when?

Key person transitions. How do you retain or transfer critical IT knowledge?

Build these into your acquisition model. The true cost of acquisition includes post-acquisition technology work.

The Negotiation Point

Technology findings affect deal terms.

Price adjustments. If you’re inheriting technical debt, that’s real cost. Reflect it in the price.

Representations and warranties. Seller should warrant that systems function, licenses are compliant, and no known security issues exist.

Escrow or holdback. For technology-dependent businesses, consider holding back funds until technology transfer is complete.

The Bottom Line

Technology is a business asset that requires evaluation just like financials, customers, and operations.

Don’t skip tech due diligence because you’re not technical. Get help if needed. The cost of discovery is small compared to the cost of inherited problems.

Ask the questions. Review the systems. Understand what you’re buying.

Because once you sign, it’s all yours, problems included.