What the IT is really worth — before you sign

We run the technology chapter and nothing else — not commercial, not financial, not legal or tax. We work alongside the advisors who do those, and we are happy to be the smallest workstream in the room.

The difference is what happens afterwards. Most IT due diligence ends at signing and hands its findings to whoever runs the integration. Our M&A references are programmes where the same team carried governance, at both architecture and programme-management level, from the due diligence through to project closure. That changes what goes in the report, because we expect to be held to it.

We scope to your window rather than to a standard timetable, and we say in advance what will not fit in it.

For reference, our own documented timetable for an unconstrained IT organisation and operations assessment is six weeks to deliver the as-is picture and a further three weeks for the risk analysis. That is the shape when nobody is holding a clock. On a transaction you do not have nine weeks, so the scope is agreed at the start: what is in, what is explicitly out, and what will be covered at interview depth rather than at evidence depth.

A short window does not change what we look at. It changes how deep we go, and how much of the report is marked as unverified — which is information the deal team needs rather than an excuse.

It is built from the workstream structure we would use to deliver the work, not from a benchmark database, and it is split into one-off and run-rate rather than presented as a single figure.

Every assumption sits next to the number it drives, so the committee can challenge them one at a time instead of accepting or rejecting the whole estimate on instinct. That is the part that survives the room: a figure with a visible assumption can be argued with, and a figure without one gets discounted on principle.

The report also states plainly what we could not see and what that leaves open. A number with a stated confidence and a named gap is more defensible than a precise one with neither — and if you need it defended in the meeting, we will come and defend it.

Less than afterwards, and we would rather be explicit about the difference than blur it.

With no access: public filings, product and hiring signals, and the target’s external technical footprint. That last one is a real measurement rather than a desk guess — external attack surface and digital risk monitoring is work we run as a service the rest of the year. It is enough to shape a view and to price the risk of not knowing; it is not enough to commit a number.

With management access: interviews and walkthroughs, enough to verify the shape of the estate and test the seller’s account of it. With a full data room: contracts, architecture, cost detail and incident history — enough to quantify integration cost and defend the figure.

And where documentation simply does not exist at any tier, we do not leave a blank. We map the area through structured expert and management interviews instead, and the report says which findings came from documents and which from conversation.

The work moves earlier and the audience changes. On the sell side we prepare the IT story before a process opens: separating what will transfer from what will not, and finding the things a buyer’s advisor will find while there is still time to fix them or price them yourself.

The expensive surprises in a sale are almost always the ones discovered by somebody else’s diligence, at the point where the only available response is a price reduction.

There is a second reason to do it properly. The separation proposal you present becomes the document the buyer’s architects work from, domain by domain, against their own target architecture and operating model. We have sat on both sides of that table. A proposal that survives contact with a buyer’s target architecture is worth considerably more than one that reads well.

A TSA is the set of services the seller keeps running for the buyer after closing: which services, for how long, on what cost basis, and on what terms they end. We have led IT TSA negotiation on the buy side and prepared the TSA on the sell side of an energy-sector merger.

Two things go wrong repeatedly. The first is agreeing a TSA in principle and discovering the price and the exit terms later, when there is no leverage left. The second is treating it as a purely technical arrangement: a TSA also reorganises people, because both sides take on roles and responsibilities they did not have the day before, and somebody has to prepare the organisation for that.

So the scope we write names the services, the duration, the cost basis, and what has to be built to replace each one. It is written to be negotiated from, not to be agreed in principle.

By testing the seller’s separation proposal against your side of the picture — your target architecture, your application landscape, your target operating model — domain by domain, before signing where access allows and immediately after where it does not.

The list of what genuinely has to work on the first morning is short and unglamorous: identity and email, payroll, finance, and whatever faces your customers. For each one the question is what it still depends on that the seller owns.

Where the honest answer is “a system that will not be separated in time”, that becomes either a transitional service or a Day 1 risk with a written fallback and a named owner. It is a great deal cheaper to find out which during diligence than in the week of closing.

It stops where it is. Our confidentiality obligation runs in both directions and does not expire: nothing that arose from the work or came to our knowledge during it — technical, legal, commercial or financial information, plans, data, procedures — is disclosed, published or reproduced to a third party without prior written consent, and that obligation survives the end of the engagement without time limit, with liability for damages if it is breached. It covers our own proposal too, in whole or in part.

In practice it means the obvious thing: a target’s diligence is never recycled into the next buyer’s.

Written document and presentation, both, because the two audiences read differently.

The core set is the as-is picture, the gap analysis, a high-level to-be description specific enough to your organisation that implementation becomes plannable from it, an action plan, and cost-reduction or efficiency proposals where we find them. On a transaction that extends to the integration or separation cost estimate, the Day 1 readiness checklist, the 100-day plan and the TSA scope input.

They are written for an investment committee first and the integration team second — which in practice means the findings have to be readable by someone who does not work in IT, and the detail behind them has to be usable by someone who does.

The analytical framework and the templates are handed over adapted to your organisation rather than to ours, so you can re-run parts of it yourself on the next deal.

Agreed, and it is the pattern this service is built against.

Our M&A references are not report deliveries. On one, we led the IT TSA negotiation and then the transformation itself across a group of telecommunications companies. On another, an energy-sector merger, the same methodology carried governance at architecture and programme-management level from the due diligence through carve-out, TSA preparation, carve-in planning and the transformation — including preparing the organisation for roles and responsibilities it had not held before.

The effect on the diligence itself is the point: estimates are written by people who expect to deliver against them. If you want only the report, you can have only the report. We would simply rather the risk register was carried into delivery than closed at signing.