Technology Due Diligence for Operators

Executive summary

Technology due diligence is the review of the systems, data, vendors and people that a target depends on, so the buyer knows what it is inheriting and what it will cost to keep running or to change. For an operator buying a mid-market business, the useful version is narrower than a full IT audit. It asks five questions. What systems run the business? What do they really cost, now and at the next renewal? What breaks if one vendor or one person goes away? How exposed is the data? And what does it take to connect this business to ours?

The goal is not to grade the technology. It is to find the findings that change the deal: a contract that resets at a higher price after close, an ERP that is out of support, a security gap that a customer or insurer will care about, a single administrator who holds all the knowledge, or an integration that will cost more than the synergy case assumed.

Each finding should land as a price adjustment, a one-time cost, a run-rate cost change, or a condition in the purchase agreement. Security, privacy, licensing and contract questions that carry legal consequences are for counsel and qualified specialists. This guide helps you ask the right questions and size the exposure. It does not replace a penetration test, a legal read of a license agreement, or a regulator's requirements.

This guide is part of the due diligence hub and pairs with the operational due diligence checklist and the financial due diligence checklist.

When to use this

Use this guide when:

• The target runs on an ERP, MES, CRM or line-of-business system that you will either keep, replace or merge into your own.
• The thesis includes a synergy that depends on shared systems, shared data or a combined finance function.
• The target holds customer, employee or health data, or sells to customers that impose security terms.
• The seller says the systems are "fine" and the only evidence is the seller's own IT manager.
• You are an operator or sponsor without in-house technical diligence capacity and need to decide where a specialist is worth the fee.

Bring in a specialist (a security assessor, an ERP implementation adviser, or counsel for license and data terms) when the target is software-dependent, regulated, holds sensitive data at scale, or when your own review turns up a red flag you cannot size. The point of the operator's review is to decide where that fee is worth spending.

Diagnostic questions

Ask these in the first technology call and in the data request. They surface the main exposures quickly.

1. Provide a list of every system used to run orders, inventory, production, billing, payroll, reporting and customer service, with the vendor, version, annual cost, contract end date and business owner.
2. Which systems are on-premise, which are hosted by a third party, and which are software as a service? Who administers each one?
3. Is each major system on a vendor-supported version, and when was each last upgraded?
4. Which contracts renew in the next 24 months, and what are the renewal terms (price caps, auto-renew, notice periods, termination for convenience, change-of-control)?
5. Who has administrator rights on the ERP, the cloud accounts, email and the domain name, and is the list reviewed at least once a year?
6. When did the company last restore a system from backup, and what was the recovery time compared with what management believes it is?
7. What security incidents, unplanned outages or ransomware events have occurred in the last three years, and what was done in response?
8. Which customers require security questionnaires, audits or certifications, and which have the company been unable to satisfy?
9. What customization exists in the ERP and other core systems, who built it, and is it documented?
10. What do the IT team and outside providers cost in total, and how much of that is fixed, how much is project spend, and how much is dependent on one individual or one managed service provider?

Framework: five technology lenses

Lens 1: Systems and architecture

Begin with an inventory, not an opinion. For each system record the vendor, the version, the hosting model, the number of users, the business process it supports, and whether it is the system of record or a shadow copy. The inventory should expose duplicated functions (two systems quoting, two places where inventory is held) and the spreadsheets that fill the gaps.

Then test fit against the plan. A system that handles today's volume may not handle the growth case, a second entity, a second currency or an integration with your own ERP. Ask the vendor or administrator what limits exist (users, transactions, modules licensed) and what it costs to lift them.

For a target that you intend to merge into your own platform, the central question is whether to migrate the target onto your systems, keep it standalone for a period, or move both to a new platform. That is an integration decision to size now and settle after close. The IT integration guide covers the sequencing, and the Tech Tax explains why legacy systems cost more than their invoice suggests.

Lens 2: Cost and contracts

Total technology cost is usually bigger than the IT line in the ledger. Software is bought by departments, outside providers are paid from operations, and some costs sit in the owner's other companies. Build the cost base from the AP ledger by vendor and compare it to the IT budget. The difference is a finding.

Then read the renewal calendar. Many mid-market technology contracts were signed at an introductory price, with annual uplifts, auto-renewals and notice windows that are easy to miss. Make a table of every contract with end date, notice date, price basis and cap on increases. Anything renewing within 24 months of close belongs in the model at the renewal price, not today's price.

Flag the following for counsel to read, and do not interpret them yourself: change-of-control or assignment clauses, audit rights over license counts, data ownership and return terms, limitation of liability, and termination fees. A license audit exposure in particular can be a real liability if the company has more users or installations than it is licensed for.

Lens 3: Data and reporting

Operators care about data in two ways. Is the reporting the buyer will rely on accurate, and can the data be moved? Ask how the five or six core KPIs are produced, and trace one from source transaction to the board pack. If it passes through a manually maintained spreadsheet, the number is only as reliable as that spreadsheet. The data foundations guide covers how to set this up properly once you own the business.

Data portability matters when you plan to migrate. Ask for a sample extract of customers, items and open orders, and check for duplicates, missing fields and inconsistent coding. Poor master data is one of the largest hidden costs of any system migration.

Lens 4: Security and continuity

You do not need to run a penetration test to ask good questions. Ask who has administrator access, whether multi-factor authentication is on for email and remote access, whether backups are separate from the production environment, and when a restore was last tested. Ask for the incident log. A company with no log is not a company with no incidents.

Review customer-imposed requirements. If key customers require questionnaires or certifications, find out whether the company currently meets them. Failing a customer's security review can threaten revenue directly. Cyber insurance is also informative: the application answers and the exclusions show what the company has represented about its controls.

Items that look material should go to a qualified security assessor. Any question about privacy law, breach notification duties or regulated data (health, financial, children's data) belongs with counsel.

Lens 5: People and vendors

Small technology teams concentrate knowledge. The administrator who built the customizations, the MSP engineer who holds the credentials, the developer who wrote the pricing macro: each is a continuity risk. Ask what documentation exists, where the passwords and recovery keys are held, and whether the seller or a relative of the seller controls any domain, cloud account or license in their own name. Transfer of those assets at close should be a condition in the agreement, handled by counsel.

Step-by-step process

1. Define what technology must do for the thesis. List the plan assumptions that depend on systems (growth in volume, a combined close, shared pricing, a cost takeout). Owner: deal lead and operating partner. Output: one-page technology hypotheses.
2. Send a short request. System inventory, contracts, invoices, access list, backup and incident records, org chart. Owner: diligence lead. Output: request list with due dates.
3. Build the cost base and renewal calendar. Reconcile technology spend from the AP ledger to the IT budget, and list every contract with end date, notice window and uplift. Owner: finance analyst. Output: cost base and calendar.
4. Interview the IT lead and the main outside providers. Use the diagnostic questions. Interview separately from the seller's finance lead and compare answers. Owner: operating partner. Output: interview notes with discrepancies highlighted.
5. Test with samples. Trace one KPI to source, review one restore test record, review the admin list, and extract master data samples. Owner: technology adviser or operator. Output: evidence notes.
6. Decide where a specialist is worth the fee. Match each unresolved red flag to a security assessor, ERP adviser or counsel. Owner: deal lead. Output: scoped specialist requests.
7. Size and type each finding. Price, one-time cost, run-rate change or condition, with a range and a confidence level. Owner: operating partner with finance. Output: findings register.
8. Reconcile with financial diligence. Confirm that run-rate technology costs and renewal uplifts are in the quality of earnings and the model. Owner: finance lead. Output: reconciled adjustments.
9. Hand over to integration. Convert open items into the first-100-day technology plan. Owner: integration lead. Output: owned actions linked to the PMI playbook.

Templates

System inventory (copy into a spreadsheet)

Contract and renewal calendar

Technology findings register

Security and continuity checklist (questions to confirm, not to certify)

Metrics and KPIs

Setting targets without invented benchmarks. Anchor technology cost to the target's own trend over three years, to what your own portfolio spends on a comparable function measured the same way, and to filings from named listed peers when they disclose the figure. Do not use a generic "IT spend as a percentage of revenue" figure from a blog as a pass or fail test. A business with heavy automation and a business with a mostly manual process should not spend the same.

Common mistakes

1. Looking only at the IT budget. Departmental software, outside providers and owner-controlled accounts sit outside it.
2. Valuing the contracts at today's price. Anything renewing within the hold period should be at the renewal price in the model.
3. Skipping the notice dates. A missed notice window can lock the company into another term at a higher price.
4. Assuming the ERP can scale because it is "the market leader". Check the version, the modules, the user limits and the customization load.
5. Accepting "we have backups" as an answer. Ask when the last restore was tested and what it showed.
6. Treating security as a certificate. Do not rely on a statement of compliance you cannot see. Ask for evidence, and send material doubts to a specialist.

Worked example

Illustrative. The numbers below are invented to show the method. They are not benchmarks.

A target with $26M of revenue provides a list of five recurring technology contracts. Each renews within the next 24 months, and each has an uplift that the target's IT lead describes as "standard". The buyer builds the renewal calendar:

Total annual cost today is $800,000. The renewal uplift adds $58,280 a year, which is a run-rate cost change. If the seller's EBITDA is built on today's prices, the buyer's model should carry the higher figure in the periods when each contract renews.

A recurring $58,280 is a price conversation, not a rounding error. Multiply it by the EBITDA multiple the deal team is actually paying to see the value effect. For example, at an assumed 7.0 times, $58,280 is about $408,000 of enterprise value. The method is the point: recurring costs that reset after close should be shown at the reset price.

The register carries three entries for this part of the review:

The buyer also notes that the ERP administrator is the sole holder of knowledge of the custom pricing macros, so retention of that person is in the key-role list for HR and counsel to handle. Taken together, the technology review changes the price a little, adds a one-time item, and adds a condition. It does not stop the deal.

AI prompt assistance

AI is helpful for organizing contract data and drafting questions. It is not a security assessor or a lawyer. Provide the documents yourself, and verify the output against the originals.

1. Build the renewal calendar from contracts.

I will paste the renewal clauses from six software contracts. For each one extract: vendor, product, annual fee, term end date, notice deadline, auto-renewal terms, any cap on price increases, and any clause about change of control or assignment. Return a table. If a field is not stated, write "not stated" and do not guess.

Check: open each contract and confirm the dates and amounts. Send change-of-control and audit clauses to counsel; do not rely on the summary.

2. Reconcile technology spend.

Here is an AP vendor listing and the IT budget. Group the vendors that are technology related into categories (ERP, security, communications, hardware, outside services, other). Show total spend by category and list the vendors that appear in AP but not in the IT budget.

Check: confirm the grouping on the top ten vendors by dollars and verify the totals tie to the ledger.

Implementation guide

Governance: the deal lead owns the register until close, and the CEO owns it afterward, with the finance lead tracking the cost items. See IT integration in post-merger integration for the sequencing of platform decisions.

Downloadable assets

The system inventory, contract and renewal calendar, findings register, security question list and provider interview questions above are designed to be copied into a spreadsheet. For the working capital side of the same transaction, see the working capital peg estimator.

Related resources

• Due diligence hub: the full set of diligence guides.
• Operational due diligence checklist: the operating layer that the systems support.
• IT integration in post-merger integration: what to do with the findings after close.
• The Tech Tax: why legacy systems cost more than their invoices.
• Vendor-led diligence vs sell-side QoE: how seller-prepared work should be tested.

Frequently asked questions

What is technology due diligence?

Technology due diligence is the review of a target's systems, data, vendors, security practices and technical staff to understand what the buyer is inheriting and what it will cost to run, fix or integrate. For operators, the practical output is a findings register that converts each issue into a price change, a one-time cost, a run-rate cost or a deal condition.

What should an IT due diligence checklist cover?

It should cover the system inventory, contracts and renewal dates, total technology cost, data and reporting reliability, security and backup practice, and dependence on key people and outside providers. For each area, list the evidence to request and what the finding will be used for, so the review ends in decisions rather than a long list of observations.

Do I need a specialist for technology due diligence?

Use a specialist when the target is software-dependent, holds sensitive or regulated data, or when your review finds a red flag you cannot size. An operator can inventory systems, read the renewal calendar and ask good questions, but security testing, license interpretation and privacy obligations belong with qualified assessors and counsel.

Why do software renewals matter in diligence?

Software renewals matter because contracts often reset to a higher price after the introductory term, with uplifts and notice windows that are easy to miss. If the seller's earnings reflect today's price, the buyer's run-rate costs are understated. List every contract that renews within the hold period and model it at the renewal price.

How this works in a System of Performance

A technology findings register loses value the day after close if the renewal dates, the owners and the fixes live in a deck. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. If you want to see where your own systems and contracts are carrying cost you have not looked at, bring it to us as a launch partner.