What technology diligence does not tell you

Technology diligence is good at the questions it was designed for. Is the architecture sound. Are the licences in order. Was there an incident nobody disclosed. Is the code base an asset or a liability. A competent provider will answer all of those, and the answers go into the model.

None of them tell you what the estate costs to run.

That is not a criticism of diligence. It is a different question, asked at a different time, by people who will not be there afterwards. Diligence describes the thing you are buying. Operating it is about who turns up on Monday, what they know, and how much of it is written down.

Three gaps show up again and again in the first year.

The first is the person nobody mapped. Most mid-market businesses have one individual who understands the part of the estate everything else depends on. The historian. The integration between the order system and the plant floor. The reporting that finance closes the month on. That person is rarely the IT director and often is not in IT at all. Diligence meets the management team. It does not meet them.

You find out who they are the week they resign.

The second is the work that was deferred rather than done. Every estate carries a queue of things postponed for a good reason at the time. A version upgrade held back because the vendor's next release was due. A firewall rule that was meant to be temporary. A server left on an operating system that stopped receiving patches, because the application on it was never certified for anything newer. Individually each was a sensible call. Collectively they are why a project that should take a quarter takes three.

Diligence sees the estate as it stands. It does not see the queue behind it, because the queue is not a document. It lives in the heads of the people who made those calls.

The third, on a carve-out, is the transition services agreement. A TSA is priced as an interim arrangement and treated as a bridge. It behaves like a meter. The seller has no reason to make the exit easy and every reason to keep the clock running, and the exit is invariably harder than the schedule assumed, because the systems were never designed to come apart. A TSA that overruns is not a line item. It is the most common single way a technology plan loses its first year.

So, three questions worth asking before the model is signed.

Ask who would have to be in the room to restore the business after a bad Friday. Not who is on the org chart. Who would actually be called. If the answer is one name, you have found a risk that diligence did not price.

Ask what has been deferred, and ask it of the engineers rather than the executives. The question that gets a real answer is not whether there is technical debt. It is what they would fix first, if they were given a month and nobody complained.

Ask, on a carve-out, what the exit looks like rather than what the TSA costs. The cost is knowable. The exit is the part that overruns, and the people who can tell you how hard it will be work for the seller and will not be yours.

None of this needs a longer diligence. It needs a different conversation, held with different people, about the year after the deal rather than the day of it. The businesses that get it right are not the ones that spent more before signing. They are the ones with somebody who had operated an estate like this before, asking the questions an operator asks.