For a private equity buyer, the starting point is the value case. A target being retained as a standalone business raises different questions from a business being separated from a seller or absorbed into an existing platform. The same technology finding can have different implications in each situation.
This technology due diligence checklist sets out how to frame those questions, examine the evidence and carry the findings into delivery. It is a guide to the assessment, not a substitute for examining the actual transaction.
1. Establish the destination before judging the estate
Begin with the operating position the investment requires. Identify what the business must do at completion, what it should be able to do during the hold and which changes the value case assumes. That gives the assessment something specific to test.
The target may run adequately today while requiring substantial work to support a different end state. Equally, replacing an existing system may add cost without contributing to the investment plan. Diligence should establish the implications of the relevant options before treating either retention or replacement as the default.
Write down the assumptions that the technology workstream needs to examine. For example: a business will operate without the seller’s services; acquired data will support combined reporting; or a platform can absorb another bolt-on. These are assessment questions. They are not conclusions to be repeated from the deal model.
2. Separate the transaction perimeter from operational dependencies
A list of assets or entities does not describe every technology service needed to operate the business. Establish which systems, data, users and support arrangements fall within the intended perimeter, then identify dependencies on services outside it.
The assessment needs to distinguish what the target controls from what it uses. Shared identity services, supplier arrangements or infrastructure may affect the work required after completion. The existence of a dependency is the beginning of the analysis: the deal team also needs to know what replaces it and what that change involves.
Keep contractual questions with the appropriate advisers. Technology diligence supplies the operational requirement and evidence about how a service is used. Counsel considers the contractual implications. Recording those responsibilities prevents a technical assumption from being mistaken for a legal conclusion.
3. Request evidence that answers a deal question
A document request should have a purpose. An application list helps establish scope. An architecture view helps examine dependencies. Cost records support the baseline. Operational evidence helps test whether a stated capability exists in the form the business needs.
The useful distinction is between a claim and the evidence supporting it. Where information is incomplete, record the limitation. Where sources disagree, identify what remains unresolved. An unverified answer should not become a confirmed finding merely because it has been repeated in several documents.
| Deal question | Evidence to examine | Implication to establish |
|---|---|---|
| What must operate without the seller? | Service dependencies and the proposed standalone position | Replacement work and transition requirements |
| What can support the intended integration? | Relevant systems, interfaces and destination requirements | Migration scope and sequencing |
| What will the estate cost after completion? | Operating cost records and change assumptions | Ongoing cost and one-time work |
| What remains unverified? | Missing, restricted or inconsistent evidence | Further assessment and decision limitations |
The table is an assessment structure, not a record of a client assignment. Its content needs to be adapted to the perimeter and the evidence available.
4. Test the data against the intended use
The presence of data does not establish its readiness for integration. A dataset may contain records while lacking the structure or completeness needed for the buyer’s intended reporting or migration. The assessment should connect data condition to the use that matters in the value case.
Consider an illustrative example: the plan depends on combined customer reporting, but records do not consistently identify the same customer across systems. The technical question is what work is required to establish the intended view. The cost and timing implications depend on the actual data and destination requirements; they cannot be derived from the existence of duplicates alone.
Where deeper profiling is warranted, define the datasets and tests as a specific assignment. Heremba’s Data Readiness & Assurance service focuses on the 5–10 datasets driving integration cost and the value case. The buyer-side assessment operates under NDA and a clean-team protocol agreed by the parties’ counsel, with findings only provided to the buyer.
5. Distinguish run cost from the cost of change
The target’s current technology spend is a baseline to examine. It is not automatically the ongoing cost of the acquired business in its intended end state. Separation, replacement services, remediation and integration may introduce costs that the current operating position does not show.
Keep ongoing operating cost separate from one-time transition work. Show the basis of each estimate and the dependencies that could change it. If an option assumes that a service can end, identify the work and conditions required before its cost can be removed.
An illustrative system consolidation may require migration and business acceptance before the replaced service can end. The programme can incur change expenditure while the old operating cost continues. A model that shows only the destination cost misses that transition. Diligence should make the overlap explicit without inventing a universal duration or savings rate.
6. Establish the technology threshold for Day 1
Day 1 needs a defined operating position. Identify the technology capabilities required for continuity at completion, including any services that will remain with the seller under agreed arrangements. Separate those requirements from the wider integration or separation end state.
This distinction informs both scope and sequencing. Some work must happen before completion; other work may continue afterwards. Diligence should identify the dependencies behind that distinction rather than assume everything can wait or everything must be finished before close.
The result should provide inputs to the readiness plan. It should identify the requirement, the evidence available and the work still needed. The authorised client decision-makers retain the decision to proceed. A technical assessment makes the position visible; it does not replace that decision.
7. Make the finding useful to the deal team
A finding needs more than a severity label. It should identify what was established, the evidence behind it, the implication for the intended plan and the next action. Where cost or timing cannot yet be established, the report should explain what information is needed.
A hypothetical seller-service dependency illustrates the structure. The finding records that the intended business relies on a service outside its destination estate. The implication identifies the need for a replacement or transition arrangement. The action establishes the assessment, decision or delivery work required. Any contractual response remains with counsel and the parties.
That structure allows the deal team to distinguish different kinds of work. Some findings require an estimate to be developed. Others require a destination decision, additional evidence or a change to sequencing. Treating them all as entries in a risk register can conceal the practical requirement.
8. Carry the evidence into the delivery plan
After signing, the delivery programme should be able to understand the diligence position without reconstructing its reasoning. The findings need to retain their evidence basis, assumptions and unresolved questions. Otherwise, a planning input can become detached from the conditions under which it was assessed.
Connect material findings to the relevant output: Day-1 requirements, separation scope, an integration roadmap or a remediation decision. The programme still needs to develop the work in detail. The purpose of diligence is to give that work a substantiated starting point and make the limits of the assessment clear.
Heremba’s B2B Information Group case records pre-deal diligence carried through to Day-1 continuity. That is the stated assignment evidence. The broader principle for a new deal is to preserve the connection between what was assessed and what the business needs to deliver.
9. Use the report to identify the decisions still ahead
The investment committee needs a technology position it can interrogate. It should be able to see the intended end state, material dependencies, cost assumptions and unresolved evidence gaps. The conclusion should make clear what has been established and what remains conditional.
A practical read-through asks whether the report answers the decision it was commissioned to support. If the model assumes a standalone estate, can the reader locate the replacement work and transition requirements? If the plan assumes integration, can the reader see the relevant data and systems dependencies? If evidence was unavailable, are the limits clear?
The report also needs to distinguish Heremba’s technical recommendations from the decisions retained by the client and the advice of other workstreams. Technology findings can inform the wider deal discussion without becoming financial, investment, legal or tax advice.
10. Scope early work without disguising its limits
A pre-LOI Rapid Read can identify the material technology questions using the information available. Its value depends on a clear relationship between scope, evidence and conclusion. It should identify what merits fuller diligence rather than imply that early access can establish every integration or separation requirement.
The same discipline applies to fuller assessment. Scope and reporting dates depend on the estate, the decision required and access to evidence. A standard timetable should not replace consideration of those inputs. Where the deadline arrives before a point can be verified, the limitation belongs in the decision material.
A checklist for the commissioning discussion
Before commissioning the work, establish the following:
- The decision: what the deal team needs to determine and by when.
- The perimeter: which entities, systems and operational dependencies are relevant.
- The destination: what the business must support at completion and during the hold.
- The evidence: what is available, what access is restricted and what requires further work.
- The outputs: the technology position, cost assumptions and delivery inputs required.
- The responsibilities: what the assessor owns and which decisions remain with the client and other advisers.
These points turn a broad request for technology diligence into an assignment that can be scoped. They also provide a basis for judging the resulting report: whether it has answered the agreed questions, made the evidence visible and identified the work the deal requires.