A managed service needs an exit test before renewal

Portability is a tested recovery path

A managed service is portable only when your team can leave it. An export button, a standard protocol and a clause in a contract are useful inputs. None proves that another environment can run the workload with its data, operational controls and acceptable interruption.

This is why the buying decision needs an exit test. The test is not a promise to migrate. It is a way to measure which parts of the service you own and which parts you would have to rebuild under pressure.

As checked on 12 October 2026, the OpenTelemetry documentation describes a vendor and tool agnostic framework for generating, collecting and exporting traces, metrics and logs. It also states an important limit: OpenTelemetry is not the storage or visualisation backend. A common telemetry path can reduce the work of changing vendors, but dashboards, alerts, retention rules and investigations can still remain specific to the current platform.

The same pattern appears elsewhere. OpenAPI 3.2.1 provides a standard, language agnostic description of an HTTP API. It can remove guesswork from calling a service, but it does not reproduce the provider's identity rules, rate limits or operational behaviour. Standards make interfaces movable. Your exit test has to cover everything around those interfaces.

Split the exit into four artefacts

Treat the service as four connected assets instead of one product name.

The first asset is the workload. Capture the source, build instructions, runtime version, environment variables, scheduled jobs and health checks needed to start it elsewhere. A container image can help, but the useful evidence is a clean deployment from the stored instructions. An image that depends on an undocumented sidecar or provider-only mount is not portable yet.

The second asset is data. Record the export format, size, consistency model, encryption handling and restore procedure. PostgreSQL's pg_dump documentation says the tool makes consistent exports while a database is in use, and that its archive formats are designed to be portable across architectures. It also warns that a dump of one database does not include cluster-wide objects such as roles and tablespaces. That warning is the broader lesson: a successful export can still omit the state that makes the application work.

The third asset is the control plane. List identities, roles, secrets, domains, certificates, queues, feature flags, network rules and provider-managed integrations. These often live in an admin console rather than the application repository. If the team cannot reproduce them from reviewed configuration or a runbook, the exit depends on memory.

The fourth asset is operations. Export or recreate service-level indicators, alerts, dashboards, on-call routes and incident notes. A workload that starts elsewhere but cannot tell the team whether it is healthy has moved its compute, not its operating capability.

Make every artefact executable

A portability document becomes stale quietly. A test fails loudly.

Create a small target environment that does not share the current provider's hidden configuration. Deploy from a clean checkout and a documented set of inputs. Restore a recent data export into that target. Point a temporary hostname at it, run a short acceptance suite and send one trace, metric and log through the replacement telemetry path.

Use harmless but representative checks:

1. create and read one record through the public API
2. process one queued or scheduled job
3. verify one role cannot access an administrative action
4. trigger one alert from the restored environment
5. rotate one test secret without using the old provider console

Keep the test isolated from production side effects. Payment calls, email delivery and customer notifications should use sandboxes or disabled adapters. The objective is to prove the boundary, not to operate two live systems.

Record each missing dependency as a named exit task. "Database restore requires three manually created extensions" is useful. "Migration needs work" is not. Give every task an owner, an estimated effort and the evidence required to close it.

Time the test before renewal

Run the test while the commercial relationship is calm. The month before renewal is useful because the result can change the decision instead of becoming a note after the contract is signed.

Measure three times separately.

First, measure hands-on engineering time. This exposes undocumented configuration and provider-specific code. Second, measure elapsed transfer and restore time. A process can require little attention but still take longer than the outage the business can accept. Third, measure the cutover window, including DNS, cache warm-up, queue draining and the point at which rollback becomes harder.

Do not turn those figures into a universal score. A service holding a replaceable preview environment can tolerate more exit work than the system that owns customer identity or billing data. Set the acceptable recovery target from the business role, then compare the test against it.

Repeat the test after a major architecture change, a new provider integration or a large data increase. Portability is a property of the current system, not the platform selected two years ago.

Turn the result into a buying constraint

The exit test changes procurement from a feature comparison into an operating decision.

Ask vendors for the exact export formats, documented API limits, deletion sequence and support available during a migration. Confirm whether exports include configuration, audit history and identity mappings, not only business rows. Put required notice periods and data-retention windows next to the technical runbook.

Then price the service with the known rebuild work. A higher platform fee can be rational if it removes maintenance and the tested exit remains within the business target. A lower fee can be expensive when the service owns an undocumented control plane or charges heavily for the transfer needed to leave.

Standards still matter. OpenAPI can keep client integration visible. OpenTelemetry can keep instrumentation independent from a backend. Database-native exports can keep the data path inspectable. Use each standard where it reduces a specific exit task, then test the parts the standard does not cover.

The acceptance condition should fit on one page: the latest test date, the four artefacts, the measured times, the unresolved provider dependencies and the next decision point. That page is more useful at renewal than a general statement that the architecture is cloud agnostic.

What this does not change

An exit test does not mean every managed feature must be avoided. Provider-specific services can be the right trade when they save enough engineering work and the business accepts the recovery cost.

It also does not guarantee a zero-downtime migration. Data volume, stateful queues, external callbacks and DNS caches can make a live cutover harder than a test environment shows. State the tested scope and keep the outage assumption explicit.

Finally, portability does not replace normal recovery. A provider migration and a production restore solve different failures. Backups, disaster recovery and incident response still need their own tests.

The useful claim is narrower: before renewal, the team can show how to rebuild the workload, restore the data, recreate the control plane and operate the replacement. Any gap is visible, owned and priced. That turns vendor lock-in from a vague fear into a set of engineering decisions.