Exit Terms Before Entry: A Cloud Contract Agenda for UK Buyers in 2026

Exit is a design requirement, not a dispute

Cloud procurement in the UK has matured, but exit terms still receive less attention than availability commitments or security schedules. That imbalance is costly. A service that performs well during the contract can become difficult to leave when data volumes grow, formats diverge and transition support is described only in general terms. For CIOs and procurement leads, the practical question is not whether an exit will occur, but whether the organisation could execute one without unacceptable disruption or unbudgeted cost.

The answer belongs in the contract, not in a later negotiation. Exit provisions should be treated as part of the service design: they define how data moves, how costs behave, how evidence is produced and how knowledge transfers. In 2026, with many UK estates comprising multiple SaaS and infrastructure providers, exit readiness is also a resilience issue. A supplier that cannot support a clean transition concentrates operational risk on the buyer.

Make portability specific

“Data export” is rarely sufficient as a contractual phrase. Buyers should require the supplier to name the formats, schemas, metadata and relationships that will be made available. For structured data, that may mean CSV, JSON or database-native dumps with referential integrity preserved. For documents and media, it may mean original file formats, folder structures, permissions and version history. For analytics platforms, it should include definitions, dashboards, queries and lineage where those are material to the service.

The clause should also address the mechanism. Is there a bulk export facility, an API, a managed transfer service or a combination? What are the throughput limits, and how often can exports be run during the notice period? If the supplier uses proprietary formats, the contract should require a documented conversion path and a test export before renewal. A useful test is to ask whether a third party could reconstruct the service from the exported material without supplier assistance. If the answer is uncertain, the portability clause is incomplete.

Cap the cost of leaving

Egress fees and retrieval charges can turn an otherwise routine migration into a board-level issue. Buyers should seek a cost cap or a defined allowance for data transfer during an exit window, with the window long enough to support parallel running and verification. The clause should distinguish between ordinary service usage and exit-related transfer, and should state how charges are calculated, when they are waived and what notice applies.

Cost certainty also depends on transition support. If the supplier will provide engineering hours, project management or knowledge transfer, the contract should quantify the commitment: named roles, response times, working hours, documentation deliverables and the number of parallel-running weeks included. A vague promise of “reasonable assistance” is difficult to enforce and easy to deprioritise when the supplier is managing other customers.

Require deletion evidence

UK organisations subject to UK GDPR and sector-specific retention rules need more than an assurance that data will be deleted. They need evidence. The contract should specify the deletion timetable, the scope of deletion across primary systems, backups, archives and subprocessors, and the form of certification. A deletion certificate is useful, but it should be supported by audit rights or access to logs where the data is sensitive.

Buyers should also clarify exceptions. Legal holds, regulatory retention and disaster-recovery copies may legitimately delay deletion, but the contract should identify them and set a final disposal date. Subprocessor lists should be current, and the supplier should confirm that deletion obligations flow down. For public sector bodies and regulated firms, this evidence may be required by internal audit or an external regulator, so it should be obtainable without a separate commercial negotiation.

Protect continuity during transition

The period between notice and cut-off is where most exit risk sits. The contract should prevent abrupt withdrawal of support, API access or administrative rights while the buyer is still migrating. It should also set out service levels for transition tasks, escalation routes and the supplier’s obligation to cooperate with a successor provider.

Where the service is business-critical, buyers should consider escrow arrangements for custom software, configuration data or documentation, together with verification testing. Escrow is not a substitute for portability, but it can reduce dependency if a supplier fails. The clause should state what is deposited, how often it is updated, who may access it and what triggers release.

A pre-signature checklist

• Name the export formats, metadata, permissions and version history included in portability.
• Confirm bulk export and API mechanisms, throughput limits and test-export rights.
• Set a capped or waived egress allowance for an exit window of adequate length.
• Quantify transition assistance in hours, roles, deliverables and parallel-running support.
• Require deletion evidence covering backups, archives and subprocessors.
• Identify retention exceptions and a final disposal date.
• Include cooperation obligations with successor suppliers and transition service levels.
• Secure audit or log access for deletion and portability verification.
• Record escrow scope, verification and release triggers where dependency is material.
• Align exit terms with internal records management, UK GDPR and sector retention policies.

Procurement tactics that change outcomes

Exit terms are more likely to survive negotiation when they are scored, not merely requested. Procurement teams can include exit readiness in the evaluation criteria and ask bidders to demonstrate a test export, a deletion certificate template and a transition plan. Legal should review the schedules alongside technical and records-management colleagues, because portability commitments often fail at the boundary between data, application configuration and infrastructure.

Renewal is another pressure point. Organisations should run a pre-renewal exit audit rather than waiting until a migration is imminent. That audit can confirm whether the current contract still matches the estate, whether export formats remain usable and whether cost caps reflect current data volumes. In 2026, the strongest cloud agreements will be those that make leaving possible without making departure punitive.