An organisation decides to move to the cloud. The pitch is well worn: elasticity, deployment speed, the end of hardware capital spend, access to managed services no in-house team could reproduce. The migration happens, the benefits arrive — real ones. Then, three or four years later, another conversation opens in the boardroom: “What would it cost us to leave?” And the answer, almost always, lands like a verdict: far too much to consider.

That moment is revealing. It doesn’t say the cloud was a bad choice — it rarely was. It says the decision was made on a single axis, the benefit, without ever examining the other: reversibility. The organisation didn’t choose the cloud; it locked itself into it. And that lock-in is not a technical inevitability: it is the outcome of a series of architecture choices, made or avoided, often without anyone measuring their reach.

This article argues a simple thesis: the real risk of the cloud isn’t the cloud, it’s irreversibility. Vendor dependence — the familiar vendor lock-in — is not an accident, it’s a design property. It can be dosed, negotiated, traded off. Provided it is treated as what it is: an architecture decision, made upfront, on the same footing as performance or cost.

The false debate: “cloud or no cloud”

The first reflex, faced with the risk of lock-in, is to reframe the question in binary terms. Should we go to the cloud or stay on-premise? Migrate everything or repatriate everything? That framing is sterile, because it pits two caricatures against each other.

On one side, the myth of the cloud as a universal answer: migrate everything, as fast as possible, without distinguishing between workloads. On the other, nostalgia for the controlled data centre, which forgets why the organisation wanted to leave it. The useful reality sits between the two, and it isn’t a position but a trajectory: which workloads go where, in what form, with what capacity to return.

The sign that the debate was badly framed is surprise. An organisation surprised by its cloud bill, surprised by the cost of leaving, surprised by a regulatory constraint discovered after the fact, is an organisation that decided without examining the trajectory. The repatriation of certain workloads — a movement seen over the past few years, as companies pull predictable workloads back onto dedicated infrastructure — is not a rejection of the cloud. It is the costly correction of migrations done without discernment. You don’t repatriate what you placed in the right spot; you repatriate what you put there by default.

The anatomy of lock-in

Lock-in is not a single phenomenon. It is a stack of dependencies that compound, each one raising the cost of leaving. Naming them is already the first step towards trading them off.

Data gravity. This is the heaviest layer, literally. The more a mass of data grows in one environment, the more processing, applications and other data aggregate around it — because it is simpler to bring compute to the data than the reverse. As that gravity settles in, moving the whole becomes an increasingly forbidding operation. The egress cost — the charge for transferring data out — is only its most visible financial expression; the real weight is architectural.

Proprietary managed services. This is the central paradox of the cloud. What creates its value — high-level, integrated services that spare the team from reinventing a distributed database, a message queue or an event engine — is also what locks in the most. An application built on standard primitives (a plain relational database, containers, open protocols) can move. An application woven around one vendor’s specific services — its serverless functions, its proprietary APIs, its identity model — does not move: it gets rewritten.

Skills. A dependence we forget to count. When teams master only one vendor’s tools, the organisation loses the very ability to imagine an alternative. Lock-in becomes cultural before it becomes technical: it’s not just that leaving would be expensive, it’s that no one would know where to start.

The contract and the economics. Multi-year commitments, volume-based discounts, egress pricing: the commercial architecture reinforces the technical one. An attractive discount obtained against a consumption commitment is a lock that doesn’t announce itself.

These four layers are not equal and are not addressed the same way. But they share one trait: none of them appears on migration day. They settle in silently, decision after decision, until their sum makes leaving unthinkable.

Reversibility is not portability

Two words are often confused, and that confusion is expensive.

Portability is a technical property: the ability to run the same workload elsewhere, ideally without modifying it. It is the ideal of the container that runs anywhere, the open standard, infrastructure described as code. Portability is necessary, but it is not sufficient.

Reversibility is a broader organisational and contractual property: the effective ability to leave a vendor within a controlled timeframe and cost, without loss of data, function or compliance. A workload can be technically portable and practically irreversible — because recovering the data would take months, because the contract forbids it, because no one has ever tested the manoeuvre.

The distinction is decisive because it shifts the question. Portability is designed in the code; reversibility is designed in the exit strategy. And an exit strategy only exists if it is written down, costed, and — the ultimate test — rehearsed. A reversibility never exercised is a hypothesis, not a guarantee. The question to ask in an architecture review is not “could we leave?” but “have we already demonstrated that we can, and at what cost?”.

Sovereignty: three layers not to confuse

Layered onto reversibility is a second concern, rising sharply in recent years: sovereignty. Here too, the word covers distinct realities that must be separated to decide well.

Data sovereignty is the best known: where the data physically resides, under which jurisdiction, with what localisation guarantees. It is the layer most organisations believe they’ve handled by ticking the “local region” box.

Operational sovereignty goes further: who, concretely, can access the data and systems, administer the encryption keys, operate the infrastructure? Data stored locally but administrable from abroad by the vendor’s staff is sovereign only in appearance.

Jurisdictional sovereignty is the subtlest and most often overlooked: to which law is the vendor subject, regardless of where the data sits? A vendor under an extraterritorial legal regime can be compelled, by its own jurisdiction, to hand over data hosted elsewhere. Physical location does not protect against legal exposure. This is precisely the point that frameworks such as the US CLOUD Act make tangible, and that Europe’s debates on trusted cloud seek to address.

These three layers call for different answers. Localising the data answers the first, not the other two. Encrypting with keys you control yourself partly answers the second. The third, the hardest, often resolves only at the level of the vendor choice itself and its legal status — hence the emergence of sovereign cloud offerings and partnerships designed to decouple technical operation from the vendor’s jurisdiction.

The regulatory context: what changed, and why this is the moment

Two recent shifts have reshuffled the deck and make the question more actionable than it used to be.

The European framework has strengthened the right to reversibility. The EU Data Act, in force since September 2025, imposes concrete switching obligations on cloud providers: framed migration timelines, standard contractual clauses that ease departure, and above all the progressive removal of switching charges — the egress fees billed for leaving are to be eliminated by January 2027. What the market once left to negotiation is becoming a right. It is a tipping point: reversibility is no longer merely an architecture best practice, it is a requirement the legal framework is starting to guarantee.

Providers have begun lowering the exit barriers. Under this regulatory and competitive pressure, the major providers announced, from 2024, free outbound data transfer for customers leaving their platform. The most visible financial lock of all — paying to retrieve your own data — is receding. It doesn’t vanish: the waiver is often conditioned on a full departure, and touches neither data gravity nor dependence on proprietary services. But the direction is clear.

For a technology leader, the practical consequence is twofold. First, the window is favourable: the balance of power is rebalancing, and negotiating reversibility clauses has never been more legitimate. Second, don’t mistake the retreat of one lock for the disappearance of all the others. Removing billed egress settles the shallowest layer; the other three — gravity, proprietary services, skills — remain intact and continue to be a matter of architecture, not law.

The Moroccan and African context

For organisations based in Casablanca, Abidjan or Dakar, these questions are not an abstract transposition of the European debate. They have their own grammar.

Personal data protection is regulated — in Morocco, by Law 09-08 and the authority that enforces it — imposing localisation and consent requirements that bear directly on hosting choices. Financial regulators, Bank Al-Maghrib foremost, tightly frame the outsourcing of credit institutions’ workloads to the cloud: risk control, reversibility, audit rights, notification. A cloud architecture for a bank in the region is not merely a technical choice, it is a case to be defended before a present and demanding regulator.

Added to this is an infrastructure reality: the availability of local cloud regions remains more limited than in Europe or North America, which raises concrete questions of latency, residency and continuity. The consequence is not to give up on the cloud, but to design deliberate hybrid trajectories, where the location of sensitive workloads and the ability to fall back are not options bolted on afterwards, but design constraints from the first diagram.

Framing the trajectory: a decision per workload

The right unit of decision is neither “the organisation” nor “the cloud”, but the workload. Each application, each data flow deserves to be placed on an explicit trajectory, according to a few criteria that, crossed together, dictate the right level of commitment and the right level of reversibility to preserve.

Criticality and sensitivity. A workload carrying regulated or strategic data does not call for the same trade-off as a test environment. The higher the sensitivity, the more reversibility and sovereignty must be examined — even at the price of a less optimised but more controllable cloud, or a hybrid trajectory.

The load profile. An elastic, unpredictable workload with sharp peaks draws maximum benefit from cloud elasticity. A stable, predictable workload running continuously draws far less — and it is precisely this kind of workload that the repatriation movement pulls back onto dedicated infrastructure, for reasons of cost and predictability.

The intensity of coupling. A workload that, to function, must lean heavily on high-level proprietary services accepts strong lock-in by definition. That is not forbidden — this coupling is often what creates the value — but it must be a conscious choice, whose exit cost is known, not a drift.

Predictable gravity. Where will the data accumulate, and at what rate? Anticipating gravity means deciding early on a data strategy — open formats, export points, possible replication — before the mass makes any manoeuvre prohibitive.

Crossing these criteria doesn’t yield a single answer; it yields a map. Some workloads will go fully into the cloud and accept strong coupling there, because the value justifies it and their criticality allows it. Others will stay deliberately portable, on standard primitives. Others still won’t migrate, or will come back. What matters is not the destination, it’s that each destination is chosen, and that the way back is known.

Keeping the exit open

Preserving reversibility does not mean giving up managed services or condemning yourself to the lowest common denominator — that would be paying for the cloud without drawing its value. It means building, from the outset, a few architecture guardrails that keep the cost of leaving under control.

Isolate the proprietary behind clean boundaries. Where you choose a vendor-specific service, encapsulate it behind an internal interface, so the rest of the system is unaware of the detail. The coupling exists, but it is confined to an identified zone — the one you’d have to rewrite on exit, and no more.

Own your data and your formats. Keeping your data in open, documented formats, having a tested export path, knowing the volume and recovery time: this is the heaviest layer of lock-in, and therefore the one that most deserves attention upfront.

Describe infrastructure as code. A reproducible infrastructure, described declaratively, turns rebuilding elsewhere from a project into an exercise. It is the technical foundation of any credible reversibility.

Write — and rehearse — the exit strategy. A reversibility plan is only worth anything once tested. Restoring an environment at another provider, even partially, once a year, turns a contractual clause into a real capability. It is also the only way to know its true cost before you need it.

Negotiate reversibility into the contract. The regulatory framework now provides leverage: exit rights, data portability, capped fees. Seize it when the balance of power is most favourable — at signature — and not when you want to leave, when it no longer is.

Conclusion

The cloud is not a trap, and sovereignty is not a slogan. They are two dimensions of the same architecture decision, too often reduced to a cost trade-off or an infrastructure question. The vendor you choose, the services you lean on, the place you let data accumulate, the clause you neglect at signature: each of these choices adds or removes a future degree of freedom.

The right question was never “should we go to the cloud?”. It is “which workload, where, in what form, and with what capacity to return?”. An organisation that can answer that for each of its systems is not locked in — even if it is massively in the cloud. An organisation that cannot is already captive — even if it still believes it has a choice. The difference isn’t decided at the moment of leaving. It’s decided at the moment of design.