An investor can acquire a healthy business and still inherit technology arrangements that are difficult to understand, expensive to sustain or almost impossible to change. A new principal can take responsibility for an established office and discover that its systems depend less on formal design than on the memory of the people who have kept them running.
Neither situation necessarily means the technology is poor. Older systems can be remarkably reliable. The question is whether the next owner understands what makes them reliable, what they cost to keep that way and what would happen if something changed.
This is where technology due diligence should begin: not with a catalogue of applications, but with the operating commitments that come with them.
Start with the work that cannot stop
Before examining servers, platforms or code, establish which processes the business must perform and what information those processes depend on. For a services business, that may be client records, billing, reporting and the ability to meet commitments. For a holding structure or family office, it may be authoritative entity records, access to custodians and administrators, and continuity of approvals.
Then ask what has to be available for those processes to work. Which systems exchange information? Who resolves an error? Who can grant or revoke access? Which activities rely on spreadsheets or manual transfers because the formal system does not quite do the job?
A diagram is useful, but I would want evidence that it matches reality. The most consequential dependency may be an old integration, an undocumented exception or a person who receives a call whenever the monthly figures do not reconcile.
Ask for proof, not reassurance
Technology diligence is often presented as a series of interviews followed by a risk rating. Interviews are necessary, but good answers need corroboration.
A claimed recovery capability can be tested through restoration evidence. A claim that access is controlled can be examined through representative permissions and approval history. The true cost of a platform emerges from licences, hosting, support, people, customisation and the work required to keep integrations alive, not only from the annual vendor invoice.
If the organisation says that a system can be replaced easily, examine the export, migration constraints and available alternatives. If its value rests on proprietary data or AI, ask who has the rights to use that data, how the relevant information is maintained and what evidence supports the technical claims. A demonstration tells you what a product can show on that day; it does not establish what the next owner is purchasing.
Where evidence is unavailable, the answer is not to assign a confident score. It is to state the uncertainty, its possible consequence and the next practical step for resolving it.
Separate inherited weakness from an immediate threat
Not every old system needs replacing. Age is not a risk measure on its own. A well-understood, adequately supported system with controlled access and tested recovery may be less troublesome than a recent platform whose costs, privileges and dependencies nobody has examined.
I would distinguish three kinds of finding.
First are exposures that could prevent the organisation from operating safely or fulfilling an important commitment: unowned privileged access, untested recovery for a critical service, unsupported infrastructure that cannot be isolated, or dependence on a departing individual for essential work.
Second are constraints that may affect the investment case: technology spending not visible in the financial model, fragile integrations, capacity limits, supplier terms that narrow the options, or a product roadmap requiring capabilities the present estate cannot support.
Third are improvements that may be worthwhile but need not determine the transaction. A cleaner interface, a better reporting tool or a future architectural simplification can often wait until ownership and priorities are settled.
Conflating these categories can make diligence both alarmist and unhelpful. The purpose is to explain which findings could change the decision, price, protections, transition plan or early operating priorities, not to manufacture an endless modernisation programme.
The first period of ownership has its own risks
A buyer may have the authority to change systems after completion but not yet have the knowledge to change them safely. Access can be transferred before dependencies are understood. A well-intended consolidation can remove the one exception that keeps an important process working.
For that reason, diligence should leave the new owner with a map of decisions, not only a list of defects. Which access rights must be secured immediately? Which contracts and critical relationships need continuity? Which records are authoritative? What should be tested before a replacement is attempted? What can be deferred without silently accepting a serious risk?
The transition plan should also distinguish technical work from matters requiring legal, financial, privacy or regulatory specialists. Technology cannot settle questions of title, legal rights or professional responsibility on its own. It can show where the operating reality makes those questions important.
A useful diligence conclusion
A worthwhile technology memorandum does not have to be long. It has to connect what was observed with what the investor or new principal is deciding. It should make the evidence, uncertainty, material dependencies, cost implications and practical next steps legible to someone who will not personally administer the systems.
The question is not whether the inherited estate would be designed the same way today. Almost nothing would be. The question is which parts can be relied upon, which commitments the new owner is accepting and how much freedom remains to choose what happens next.