Before the ink dries: an IT integration diagnostic for UK acquirers

Acquisition business cases are usually built around revenue, market position and operational synergy. The technology estate is treated as a post-completion workstream, staffed after the deal is signed and funded from a contingency that is rarely sized with any precision. The result is a familiar pattern: duplicate licences, data migration debt, cyber gaps and architecture clashes surface in the first hundred days, just as the business is trying to protect customers and retain key staff.

That is the integration tax. It is not a single invoice. It is the cumulative cost of discovering, reconciling and rebuilding technology that two organisations have each evolved separately. For UK acquirers, the tax is especially visible in supplier contracts, regulatory obligations and the practical difficulty of separating shared services at speed.

What the integration tax actually contains

The tax rarely appears as a line item called integration. It hides in several places. Licence duplication is common where both businesses hold overlapping SaaS subscriptions, often with different renewal dates and volume commitments. Data migration debt arises when master data, retention schedules and reporting definitions were never designed for combination. Cyber gaps appear when identity, endpoint management and supplier assurance follow different standards. Architecture clashes surface when one estate is cloud-first and the other remains dependent on a small number of unsupported on-premises applications.

There is also a people dimension. Integration work competes for the same small group of architects, contract managers and security specialists who are already keeping the current estate running. If those people are not identified before completion, the plan will look affordable on paper and stall in practice.

A 30-day diagnostic

The diagnostic should run before signing, or as confirmatory due diligence if exclusivity has already been granted. It needs a small team with access to the data room, contract register and key technical staff. Thirty days is enough to produce a board-grade view if the scope is controlled.

Days 1 to 5: establish the baseline

Build a fact base rather than a wish list. Collect the asset and licence inventory, the top twenty supplier contracts, an architecture map, data flow diagrams, cyber control summaries and a list of key-person dependencies. Ask for renewal dates, termination notice periods, change-of-control clauses and any minimum volume commitments. The aim is not a perfect inventory; it is a defensible view of where the material exposure sits.

Days 6 to 10: quantify duplication and liability

Compare the two estates side by side. Identify overlapping software categories, unused capacity, duplicate reporting platforms and suppliers that will need novation or termination. Estimate data migration effort by domain, not by database. Assess unsupported systems, end-of-life hardware and any security exceptions that would fail the acquirer's own standards. At this stage, ranges are more useful than false precision.

Days 11 to 15: test architecture and data realities

Review integration patterns, identity and access management, cloud tenancy arrangements, API estates and master data ownership. Interview the people who run the systems, not only the people who procured them. The question is not whether the target architecture is elegant. It is whether the two estates can be connected, separated or consolidated without breaking regulatory reporting, customer service or payroll.

Days 16 to 20: model cost and risk

Build a three-scenario model: minimum intervention, controlled consolidation and accelerated transformation. For each, estimate one-off cost, recurring run cost, synergy confidence and delivery risk. Include the cost of retaining key staff through the integration period. Show the board what happens if synergies are delayed by six months, because that is often the more realistic case.

Days 21 to 25: define options and quick wins

Group decisions into retain, consolidate, replace and migrate. Identify quick wins that reduce cost or risk without creating new dependency, such as terminating duplicate subscriptions at renewal or closing unused accounts. Sequence the work by value, risk and dependency. Avoid a single big-bang integration unless the evidence genuinely supports it.

Days 26 to 30: produce the board pack

The output should be concise and decision-oriented. It should include an integration tax range, a confidence rating for each synergy, the top ten risks with owners, a decision log, a hundred-day plan and a clear funding request. It should also state what the acquirer will not do in the first year, because integration fails when everything is treated as urgent.

What the board should see

Directors do not need a technical inventory. They need four things: the likely cost range, the assumptions that would change it, the decisions required before completion and the risks that could affect customers or regulatory standing. A one-page heat map of systems, suppliers and data domains is often more useful than a long appendix.

The diagnostic should also test the deal thesis. If the synergy case depends on consolidating two ERP estates within twelve months, the board should see the evidence for that timetable. If it depends on renegotiating a small number of supplier contracts, the board should see the notice periods and change-of-control terms. The integration tax is not only a cost; it is a test of whether the value case is credible.

A prioritised plan, not a promise

The final plan should be prioritised, funded and owned. It should distinguish between work that protects the business, work that delivers synergies and work that transforms the combined estate. That distinction prevents the integration programme from becoming a general IT upgrade with no clear return.

UK acquirers who run this diagnostic before signing do not eliminate uncertainty. They price it more honestly. That is the practical purpose of the exercise: to ensure the board approves the deal with its eyes open, and the integration team starts with a plan rather than a surprise.