After the Handshake: Budgeting for the Integration Work That Starts at Go-Live

The Moment the Project Plan Ends

A technology project has a visible climax: go-live. The steering group meets, the supplier sends a congratulatory note, and the internal team moves on to the next priority. What the project plan often does not show is the second phase of work that begins the following Monday. Data that does not match. Reports that need rebuilding. A connection between two systems that worked in testing but fails under real volume. Staff who understood the training session but cannot yet run the process without support.

This is the integration tax: the accumulated cost of making a new tool work alongside everything else. It is rarely a single line in the business case. It appears instead as internal time, contractor invoices, vendor change requests, and delayed benefits. For UK SMEs, where finance teams are lean and management attention is finite, the tax can be large enough to change the return on the original investment.

Where Integration Costs Actually Appear

The first place is the API gap. Vendors often describe their product as having an “open API” or “standard connectors”. Those phrases are true but incomplete. The API may exist, but the specific endpoint your process needs may not. The connector may be standard, but the mapping between your data fields and the vendor’s schema may be bespoke. The cost is not the connection itself; it is the specification, testing, and maintenance of the connection over time.

The second place is data clean-up. Every system migration exposes the quality of the source data. Duplicate customer records, inconsistent VAT codes, missing cost centres, and legacy free-text fields all become visible when they are pushed into a new environment. Cleaning that data is necessary work, but it is rarely included in the software subscription. It is either absorbed by internal staff or commissioned as a separate project.

Middleware, APIs, and the Ownership Question

Middleware is the layer that connects systems, and it is often the least clearly owned part of an integration. The vendor may say the middleware is “supported”, meaning it will not break the connection, but not that it will build the mapping your business requires. The internal IT team may say the middleware is “the vendor’s responsibility”, meaning the supplier should have configured it. The result is a gap between two reasonable positions, filled by a contractor or an internal specialist at additional cost.

UK buyers should settle this question in the contract. Who specifies the integration? Who builds it? Who tests it? Who monitors it after go-live? Who pays for changes when either system is updated? A simple RACI table — responsible, accountable, consulted, informed — attached to the statement of work can prevent a costly dispute later.

Retraining and the Internal Time Ledger

Training is usually budgeted as a one-off event: a set of sessions, a user guide, perhaps a super-user programme. The integration tax includes the less visible retraining that happens after go-live, when staff discover the exceptions and edge cases that the training did not cover. That time is real, even if it does not appear on an invoice. It shows up as slower processing, temporary overtime, or a drop in service levels.

A useful budgeting technique is to create an internal time ledger for the first six months after go-live. Estimate the hours each team will need for data checking, error correction, workaround development, and informal peer support. Cost those hours at a realistic internal rate. The figure will not be precise, but it will be better than treating internal effort as free.

Drawing the Vendor Boundary in the Contract

The most effective way to control the integration tax is to make the boundary explicit before signature. Ask the vendor to list what is included in the implementation fee and what is chargeable. Ask for day rates for post-go-live change requests. Ask whether integration support is covered by the subscription or billed separately. Ask what happens when a third-party API changes and the connection needs updating.

Where the vendor cannot commit to a fixed scope, ask for a capped estimate. Where the vendor cannot provide an estimate, treat that as a risk to be priced internally. The goal is not to eliminate uncertainty; it is to ensure the uncertainty is visible to the people approving the budget.

A Budget Line for the Unseen

UK SMEs do not need to abandon ambitious technology projects. They need to budget for the work that follows the handshake. That means adding a post-go-live integration line to the business case, including internal effort as well as external spend. It means asking the ownership questions early. And it means recognising that a successful go-live is not the end of the project; it is the start of the period in which the real cost of integration becomes clear.