Expiry Dates for the Digital Plumbing: The Case for an Integration Sunset Register
Photo: Bill Bradford, CC BY 2.0, via Wikimedia Commons
Most UK digital transformation programmes can produce a service catalogue. They can tell you which applications are owned by which directorate, when the licence renews and whether the system sits in a hyperscaler or a council data centre. What they cannot usually produce is a list of the integrations between those systems: the REST endpoints, message queues, file drops, screen scrapers and middleware channels that make the catalogue behave like a service rather than a shelf.
That gap is becoming expensive. As programmes consolidate platforms and retire legacy estates, the integration layer is often the last thing to be documented and the first thing to break. A routine upgrade to an authentication provider, a change in a payment scheme’s API version or the withdrawal of a vendor’s support contract can turn into a public-facing outage because nobody held the connector’s expiry date.
The answer is not another enterprise architecture diagram. It is a retirement calendar: a maintained record of every integration that matters, with an owner, a dependency map and a tested exit route. In 2026, that should be a board-level expectation for any UK organisation running critical digital services.
What the calendar records
A useful register starts with three fields that most integration inventories lack: the business service the connector supports, the date by which it must be replaced or removed, and the person accountable for that decision. The first prevents technical teams from treating an API as an end in itself. The second creates a forcing function. The third makes the difference between a plan and a wish.
Around those fields, add the practical detail: the protocol and version, the authentication model, the data classification, the upstream and downstream systems, the contractual notice period, the monitoring in place and the date the exit route was last tested. For public sector bodies, add the framework or shared service through which the integration is procured; for regulated firms, add the reporting obligation that depends on it.
None of this is exotic. It is the same discipline that asset managers apply to physical plant. The novelty is applying it to the connective tissue of digital services, where change is frequent and documentation decays quickly.
Exit routes are engineering, not paperwork
A retirement date without a tested exit route is a deferral dressed as governance. Teams should be able to demonstrate, before the date arrives, that they can move traffic to a replacement endpoint, replay or reconcile data, and roll back if the new path fails. For high-volume integrations, that means a dry run in a pre-production environment with representative data and a named incident commander.
The test should also cover the unglamorous cases: what happens when the upstream system is unavailable during the cutover, how the service behaves if the new connector returns malformed data, and who communicates with users if the change window overruns. These are the scenarios that turn a planned retirement into an unplanned outage.
Contractual exit matters too. Notice periods, data extraction rights and support obligations should be recorded alongside the technical route. A connector that cannot be exited without a six-month negotiation is not really scheduled for retirement; it is scheduled for a conversation.
The governance test: can you name the person?
Ask a simple question of any integration in the estate: who owns the decision to retire it? If the answer is a team name, a committee or a vendor, the register is not yet working. Ownership needs a named individual with the authority to commission the replacement work and the accountability for the service if the exit slips.
That person does not need to be a technologist. In many cases, the right owner is the service owner in the business, supported by an integration lead. What matters is that the date appears in the same planning cycle as licence renewals and platform upgrades, not in a separate architecture forum that meets quarterly.
Start with the integrations nobody owns
The most useful first move is to list the connectors that have no obvious owner: the scheduled file transfer between a finance system and a reporting warehouse, the middleware link between a contact centre and a case management tool, the API that a partner organisation relies on but no internal team monitors. These are the candidates for the graveyard.
Then rank them by blast radius rather than technical elegance. An integration that supports a statutory service, a payment flow or a safety-critical process deserves attention before an internal reporting feed. The register should be short enough to be maintained and complete enough to be trusted.
A calendar, not a monument
The risk is that the retirement calendar becomes another document that is created, praised and abandoned. Avoid that by tying it to existing rituals: change advisory boards, service reviews, procurement gateways and annual budget setting. Report the number of integrations past their retirement date with no tested exit, and treat that number as a service risk, not a housekeeping metric.
UK digital teams have spent years learning to catalogue applications. The next step is to catalogue the connections between them and to give those connections an end. A connector with no expiry date is not a permanent asset; it is a future incident waiting for a routine upgrade to reveal it.
