Is this different from the migration service?

Yes. The migration service moves a workload from A to B. Reversibility engineers the freedom to move again (off B) and produces a tested exit plan as its deliverable. You can buy it standalone to harden a provider you already run, or as the exit half of a migration.

Does reversibility mean avoiding every managed service?

No. Refusing all managed services is its own cost. The goal is deliberate lock-in: you know exactly which proprietary hooks you accepted, why, and what it would take to remove each. Reversibility is a documented decision, not asceticism.

Why does a regulator care about our exit plan?

EU rules such as DORA expect firms to manage concentration risk in critical ICT third parties, which includes being able to exit or substitute a provider. A tested reversibility plan is the evidence that the risk is managed rather than asserted.

Will you make us reversible away from SaveOps too?

That is the point. Everything is infrastructure-as-code and runbooks in your repositories, operable by your team. A reversibility engagement that left you dependent on us would contradict its own thesis.

Cloud reversibility

Cloud reversibility: an exit you can actually execute

Reversibility (réversibilité) is the ability to leave a cloud provider (the one you are on now, and the one you move to next) without a rewrite and without a hostage negotiation. It is increasingly a regulatory expectation, not just good hygiene. SaveOps builds it as a standalone engagement: a documented, tested exit plan and a target architecture designed so you are never locked in again.

What reversibility actually buys you

A cloud you cannot leave is a supplier with pricing power over you. Reversibility is the engineering that removes that leverage before you need it.

Negotiating leverage A provider you can credibly leave in weeks, not years, is a provider you can negotiate with. Lock-in is the reason renewal quotes only ever go up.
Regulatory defensibility EU frameworks increasingly expect a documented exit strategy for critical cloud dependencies. A reversibility plan is the artifact an auditor (or a DORA reviewer) asks to see.
Resilience, not just exit The same portability that lets you leave lets you fail over, split across providers, or survive a supplier going under. Reversibility and resilience are the same engineering.
Freedom from the next lock-in Moving off AWS onto a provider you cannot leave either is not sovereignty. We design the target so proprietary hooks are the exception you chose, not the default you inherited.

How we build an exit plan

Reversibility is a deliverable, produced in order. It works whether you are exiting a hyperscaler now or hardening a provider you already run.

Lock-in audit We inventory every dependency that would make you hard to move: proprietary managed services, data-egress cost, identity and IAM coupling, licensed marketplace software and contractual commitments. The output is a ranked map of what pins you where.
Portability design We rework the estate toward portable foundations (open formats, standard APIs, infrastructure-as-code, containerised workloads) so the substitutable layer stays substitutable. Where a proprietary service earns its keep, that becomes a deliberate, documented choice.
Exit runbook We write and version the exit procedure: the order of operations to move data and workloads off the provider, the egress plan, the DNS and cutover steps, and the rollback path. A plan that has never been read is not a plan.
Rehearsal We test the exit on a real slice (stand the workload up on an alternative, move real data, measure the time and cost) so the runbook reflects what actually happens, not what the diagram assumes.
Handover of the dossier You keep the reversibility dossier: the lock-in map, the portability decisions, the tested exit runbook and the cost/time estimates. It lives in your repositories and is yours to maintain, including to use against us.

What a clean handover artifact contains

The reversibility dossier we hand over is a concrete document set, not a promise. It contains:

A ranked inventory of every lock-in vector (proprietary service, egress cost, IAM coupling, contractual commitment) with its cost-to-remove.
Infrastructure-as-code for the whole estate, in your repositories, so the environment is reproducible without the provider console.
A versioned, tested exit runbook: the ordered steps, the data-egress plan, the cutover and the rollback path.
Directional time and cost estimates for an actual exit, measured against a rehearsed slice rather than guessed.
The list of deliberate proprietary dependencies you chose to keep, so the next team knows exactly where the remaining friction is.

Questions procurement and platform leads ask

Is this different from the migration service?: Yes. The migration service moves a workload from A to B. Reversibility engineers the freedom to move again (off B) and produces a tested exit plan as its deliverable. You can buy it standalone to harden a provider you already run, or as the exit half of a migration.
Does reversibility mean avoiding every managed service?: No. Refusing all managed services is its own cost. The goal is deliberate lock-in: you know exactly which proprietary hooks you accepted, why, and what it would take to remove each. Reversibility is a documented decision, not asceticism.
Why does a regulator care about our exit plan?: EU rules such as DORA expect firms to manage concentration risk in critical ICT third parties, which includes being able to exit or substitute a provider. A tested reversibility plan is the evidence that the risk is managed rather than asserted.
Will you make us reversible away from SaveOps too?: That is the point. Everything is infrastructure-as-code and runbooks in your repositories, operable by your team. A reversibility engagement that left you dependent on us would contradict its own thesis.