The Integration Will: Why UK Public Tech Must Plan for the Vendor’s Exit

Public technology rarely fails in a single dramatic moment. It degrades through small dependencies: an authentication endpoint that changes, a data schema that drifts, a sandbox that is withdrawn, or a supplier acquired by a larger company with a different product roadmap. For UK councils, NHS trusts and arm’s-length bodies, these are not hypothetical risks. They are operational realities that surface when a service is already embedded in casework, referrals, payments or regulatory reporting.

The problem is not that vendors change APIs. The problem is that public bodies often have no agreed route out when they do. Contracts may specify uptime, security and support, yet say little about who owns the schema, how changes are tested, what rate limits apply during migration, or what happens to documentation if the supplier exits the market. In 2026, that gap should be treated as a procurement defect.

Dependency grows quietly

Most public-sector integrations begin as sensible shortcuts. A team buys a specialist service rather than rebuilding it. The API is documented, the pilot works, and the integration moves into business-as-usual. Over time, the API becomes part of the institution’s operating model. It may sit behind a housing benefits workflow, a clinical correspondence system, a grant management platform or a licensing service.

The dependency is often poorly mapped. Technical teams know which systems call the API, but not always which business processes depend on the response. Commercial teams know the contract value, but not the cost of replacing the integration. When a supplier is acquired, reprices its tiers or changes its deprecation policy, the public body discovers that its bargaining position is weaker than its operational exposure.

This is especially acute in local government, where digital teams are small and procurement capacity is stretched. A council may run dozens of integrations across adult social care, revenues and benefits, planning and environmental services. Each one looks manageable in isolation. Together they form a portfolio of continuity risk that no single contract owner sees in full.

An exit-ready contract is a technical document

An integration will is not a legal formality. It is a set of technical and commercial commitments that make departure possible without service failure. For public bodies, several clauses deserve to be standard in 2026.

Schema ownership and change control. The public body should own the canonical data model it depends on, even if the vendor supplies the API. That means agreed definitions, versioning rules, deprecation notice periods and a change log that is published before breaking changes reach production. Vendors should not be the sole custodians of the mapping between their payloads and the public body’s business objects.

Test harnesses and contract tests. A sandbox is not enough if it does not reflect production behaviour. Contracts should require a maintained test harness, representative fixtures and automated contract tests that both parties can run. When an API version changes, the public body should be able to prove whether its integration still works before residents or patients are affected.

Rate-limit guarantees. Rate limits are often buried in fair-use policies. During migration, they become critical. A contract should define baseline request thresholds, burst allowances, monitoring arrangements and notice periods for changes. It should also guarantee that migration traffic will not be throttled in a way that prevents bulk export or parallel running.

Documentation escrow. API documentation, OpenAPI specifications, authentication flows, data dictionaries, sample payloads and operational runbooks should be held in escrow with clear release triggers. If a supplier ceases trading, is acquired and withdraws the product, or fails to meet documentation obligations, the public body should receive the material it needs to maintain or replace the integration.

Migration clauses with practical effect. Exit rights are weak without migration assistance. Contracts should specify export formats, data retention and deletion terms, parallel-running periods, transition support hours and a fee schedule for migration work. The clause should be tested, not merely signed. A annual tabletop exercise is useful; a technical rehearsal on a subset of data is better.

Procurement is where continuity is won or lost

These requirements are often discussed after the contract is awarded. That is too late. API continuity should appear in the evaluation criteria, the statement of requirements and the contract schedules. Bidders should be asked for an endpoint inventory, a dependency map, a deprecation policy, a security model and a migration plan. The answers will differentiate suppliers more meaningfully than another promise of partnership.

Public bodies can also pool leverage. Shared frameworks, standard clause libraries and common assessment questionnaires reduce the cost of due diligence and make exit readiness a market expectation rather than a bespoke negotiation. NHS trusts, local authorities and arm’s-length bodies buy similar capabilities from similar suppliers. They should not each rediscover the same integration risks in isolation.

Treat continuity as a governance routine

An integration will is not a one-off document. It needs an owner, a review cycle and a register. Technical teams should maintain a dependency map that links APIs to business services, contract owners and replacement options. Commercial teams should track notice periods, escrow releases and migration obligations. Senior responsible officers should see the aggregate risk, not just the status of individual projects.

None of this is pessimistic. It is the same discipline public bodies already apply to estates, suppliers and data protection. Digital services deserve equal seriousness. A vendor may leave for entirely ordinary reasons: acquisition, consolidation, a change of strategy or a better market elsewhere. The question is whether the public body can continue to serve residents and patients when it does.

In 2026, API continuity should be a condition of doing business with the public sector. An integration will is not a sign of distrust. It is evidence of competent stewardship.