Exit Is an Architecture, Not a Clause: Making Cloud Portability an Integration Discipline

For much of the last decade, cloud portability was treated as a procurement problem. The theory was that if you negotiated hard enough — a cap on egress charges, a termination assistance clause, a commitment to return data in a usable format — you had preserved your ability to leave. UK buyers now have more leverage on those terms than at any point in the last decade, following the Competition and Markets Authority's scrutiny of the cloud services market and the hyperscalers' own decisions to rethink egress pricing.

And yet the organisations that struggle most to move are rarely blocked by contract language. They are blocked by the fact that their identity model, their event schemas and their data pipelines only make sense inside one provider. The agreement says they may leave. The architecture says they cannot.

Where lock-in actually lives

It helps to separate the estate into four layers, because they behave very differently when tested.

Infrastructure is the most portable. Virtual machines, containers and object storage are broadly substitutable, and the migration tooling is mature. This is the layer procurement teams tend to picture when they discuss exit.

Platform services sit in the middle. Managed databases, serverless functions and message brokers have close equivalents elsewhere, but the equivalents are rarely identical, and the differences concentrate in operational behaviour rather than in the API surface.

Integration is where switching costs accumulate fastest and least visibly. Identity constructs, proprietary queue semantics, vendor software development kits imported into domain code, event serialisation formats and mandatory observability agents all create dependencies that no contract clause can dissolve.

Data is the layer everybody names and few actually measure. Volume matters less than dependency: a dataset that twenty services read from is heavier than one ten times its size that nothing else touches.

Pattern one: an anti-corruption layer between domain and vendor

The most reliable defence is a boundary that vendor concepts cannot cross. Domain code should call an internal interface expressed in the organisation's own vocabulary; an adapter translates that into whatever the provider's SDK expects. No vendor types, no provider-specific error codes and no proprietary pagination tokens should appear above that line.

The cost is real: extra code to maintain and, occasionally, a small amount of latency. The benefit is that replacing a provider becomes a rewrite of the adapter rather than an archaeology exercise across the entire codebase. For teams that have not done this, the practical starting point is to inventory where vendor SDKs are imported and treat each one as a candidate for wrapping.

Pattern two: treat data gravity as a budget line

Data gravity is genuine, but it is frequently invoked to justify decisions it should only inform. The discipline is to classify datasets explicitly — by volume, by egress cost, by the number of services that depend on them — and to record which are system of record and which are derived.

Portability then follows from a small number of habits. Keep authoritative data in open formats where the workload permits, with schemas managed in a registry rather than in application code. Test restore as well as export, because an export that has never been loaded into a different environment is a hypothesis rather than a capability. And be honest about which datasets would never move. A petabyte-scale analytics store may reasonably stay put; the mistake is discovering that decision by accident during a migration.

Pattern three: identity that federates rather than embeds

Identity is the hardest layer to re-platform, because it touches every user and every service. The portable approach rests on standards: OpenID Connect for authentication, SAML where required for legacy federation, and SCIM for provisioning. Authorisation logic should depend on entitlements held in the organisation's own directory rather than on provider-specific group identifiers pasted into policy documents.

Workload identity deserves the same treatment. Where standards-based options exist, they reduce the amount of provider-specific plumbing embedded in deployment pipelines and service configuration.

Pattern four: decouple with queues and contracts, not with vendor features

Event-driven architecture is portable when the contract belongs to the organisation and fragile when it belongs to the broker. Three practical rules follow. Assume at-least-once delivery and design consumers to be idempotent. Avoid depending on proprietary delay, visibility or scheduling semantics whose behaviour cannot be reproduced elsewhere. Publish schemas and run contract tests so that a replacement broker can be validated against the same expectations.

The same logic applies to observability. Instrumenting with OpenTelemetry and treating the vendor's agent as optional rather than mandatory keeps telemetry portable when the backend changes.

The exit rehearsal

Architecture documents age badly. A rehearsal produces evidence. Once a year, take one tier-one workload and move a copy of it to a second environment — not a full migration, just enough to measure. How long did it take? What broke? Which runbook was wrong? What did the egress actually cost?

The exercise is uncomfortable and therefore useful. It converts exit from a theoretical property into a measured one, and it usually surfaces two or three dependencies that no diagram had captured.

What exit-ready should mean on a 2026 architecture roadmap

The phrase exit-ready is often used loosely. It is worth defining it precisely enough to be auditable:

1. Every tier-one workload has a documented exit route, a cost estimate and a recovery time objective that the business has accepted.
2. Data export and restore have been tested within the last twelve months, with results recorded.
3. Identity is federated on standards, and no provider-specific group identifiers appear in authorisation policy.
4. A conformance and contract test suite exists and can be run against a second provider in continuous integration.
5. Exit cost is modelled alongside run cost in every major investment business case, not added afterwards.
6. Contract terms match architectural reality: termination assistance, egress treatment and data return formats are aligned with what the estate can actually do.
7. A named owner is accountable for exit readiness, and the rehearsal appears in the assurance calendar.

The commercial argument

Portability is not free. Abstraction layers cost performance and engineering time, and running a second environment for rehearsal costs money. The return is optionality: negotiating leverage at renewal, resilience when a provider has a bad quarter, and the ability to adopt a better service without a two-year programme.

For UK organisations operating under close regulatory attention to operational resilience and third-party dependency, that optionality is increasingly less a nice-to-have than part of the evidence base. The contract gives permission to leave. The integration layer determines whether leaving is possible.