Ask ten infrastructure teams whether they have a cloud exit strategy and nine will say yes. Ask what it consists of and you usually get a wiki page written during a vendor review, listing which services are proprietary and which are portable. That is an inventory, not a strategy. The real test is less comfortable: if your provider doubled its prices, changed jurisdiction, or suspended your account on a Tuesday morning, how many weeks until you are serving traffic somewhere else - and who on your team can answer that without opening a spreadsheet?
The regulatory pressure here is real but it is not the interesting part. The Data Act is removing switching charges, which takes away the finance department's excuse. Schrems II and the CLOUD Act took away the legal one years ago. What remains is engineering reality, and no directive fixes that. A regulator can make leaving cheaper on paper; it cannot make your deployment pipeline, your identity model, your DNS records and your restore path work at a second provider. That work is yours, and it is the entire cost.
What a cloud exit strategy actually is
An exit strategy is a measurable property of your architecture, not a document. The measurement is blunt: what share of your running estate could you stand up at a different provider, using tooling you already operate, without writing new code? For most teams the honest answer lands somewhere between forty and seventy percent, and the gap is never where they expected. It is rarely the application. It is the managed database, the queue, the object storage semantics, and the eleven small operational habits nobody ever wrote down.
The failure mode is believing that having two providers proves anything. Plenty of companies run production on one hyperscaler and a forgotten test project somewhere else, then call the result multi-cloud. Optionality is not the presence of a second account; it is the ability to exercise it. Until one real workload - with monitoring, backups, an on-call rota and a restore you have actually performed - runs somewhere other than your primary provider, you have a second invoice, not a second option.
The three things that make leaving hard
First, data gravity, which is boring and decisive. Bytes are cheap to copy and expensive to move consistently while a system is live. The moment your data sits inside a proprietary managed service, the exit stops being a copy and becomes a rewrite of everything that talks to it. This is why teams that keep their state in something they could run themselves - even if they choose not to today - preserve options that teams on fully managed stacks quietly lose over a few years.
Second, operational muscle memory. Your team knows one provider's identity model, one firewall abstraction, one way of naming networks, one console layout at three in the morning. Move to a second provider and every one of those is unfamiliar under pressure. The cost is not the migration weekend; it is the following six months of incidents handled a little more slowly by people who are guessing. Nobody puts that on a migration estimate, and it is usually the largest line on it.
Third, cost attribution. Most teams cannot tell you what a single workload costs today, which makes comparing providers impossible in principle. If your bill is one number per provider and your architecture is forty services, the exit conversation degenerates into vibes. Before you can price an exit you need spend broken down by service, project and environment, across every provider you use, including the small ones you forgot about. It is unglamorous groundwork, and it is a prerequisite for every other decision here.
How to avoid cloud vendor lock-in in the EU
If you want to avoid cloud vendor lock-in, the EU market is in better shape than most teams assume. Hetzner's price-performance makes hyperscaler invoices look like a rounding error in the wrong direction. OVHcloud runs its own data centres and fibre across Europe. Scaleway ships a genuinely modern developer experience from France. UpCloud delivers dependable compute from Finland. None of them replaces every hyperscaler service - but for compute, block storage and networking, where most infrastructure money actually goes, they are credible and answer to EU law alone.
The honest limit is managed services. If your product is built on a proprietary serverless database, a specific event bus, or a machine learning platform with no equivalent elsewhere, no amount of European enthusiasm changes that within a quarter. The useful move is not a heroic all-or-nothing migration. It is to know exactly which workloads are portable today, run some of them where the jurisdiction and the price suit you, and treat the rest as a deliberate, documented decision rather than an accident of history.
What an exit rehearsal actually involves
Treat it like a restore drill, because that is what it is. Pick a real workload - not the marketing site, something with state and a runbook. Stand it up at a second provider. Point a fraction of real traffic at it. Break it deliberately and see whether your monitoring, your access model and your on-call rota work there too. Then write down the wall-clock time and everything that surprised you. A rehearsal that produces no surprises usually means you picked something too easy.
The reason most teams never rehearse is not laziness, it is tooling. Every additional provider means another console, another credential model, another billing export, another set of quirks to learn - and a small platform team cannot absorb that once per cloud. This is the operational tax that quietly converts a sovereignty conversation into next year's problem, every year. It is also, precisely, the problem a control plane is supposed to remove from your desk.
That is what we built Sencai to be. One control plane across eleven providers - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai's Linode and Oracle Cloud - plus your own servers through a host agent. Networks, firewalls and DNS are managed where they actually live, at the provider, so a second provider becomes a tile in the same interface rather than a second platform team. Spend is tracked per organisation with caps, so the exit conversation has numbers in it.
You can run this on your own provider accounts, or buy the capacity through us and keep one invoice - both are supported, and the choice is yours to change later. Either way the deliverable is the same, and it is the only number worth reporting upward: how long it would take you to be running somewhere else. Measure it once and it stops being a fear. Measure it every quarter and it becomes leverage - in a negotiation, in a procurement review, and on the day something forces the question.