Migration to European sovereign cloud
Dependence on a non-European hyperscaler can be reduced by moving workloads to European providers such as Exoscale, STACKIT or OVHcloud, and the way to keep that migration from creating a new dependency is to build it on Kubernetes and infrastructure as code. We start with an honest assessment: which services have an equivalent, what actually ties you to the current provider, what it costs to move and what functionality is lost. If the answer is that it is not worth it, we say so in the same report.
Last updated:
What really ties you to a hyperscaler
Who it is for
For technology companies with a concrete reason to move their infrastructure to Europe: a public-sector customer asking for it in a tender, a regulated-sector requirement, the risk of depending on a jurisdiction that is not yours, or simply a bill that has grown without anyone questioning it.
What it solves
Leaving a hyperscaler is difficult by design. What ties you is not the virtual machine, which moves in an afternoon: it is the managed services with no exact equivalent, the cost of getting the data out, the serverless functions bound to their ecosystem, identity management, and the amount of configuration that lives in the web console and in no repository. If that is not inventoried first, the migration turns into a project with no end.
The part that matters: not repeating the problem
Changing provider only to get locked into the next one solves nothing. That is why the architecture rests on Kubernetes, Terraform and services with standard interfaces — S3, Postgres, Kafka — and the configuration lives entirely in your repository. The test for calling a migration good is being able to repeat it: if moving the infrastructure to a third provider would again be a months-long project, something was done wrong.
How it differs from Cloud Independence
Cloud Independence is for the company that wants to leave Microsoft 365, Google Workspace or AWS as far as its office work is concerned: email, files, documents, video calls. This is for the company with its own product running on a hyperscaler that wants to move it without anyone noticing. If both apply to you, start with whichever has the deadline attached.
The three phases of the work
Assessment
An inventory of services in use, the equivalent at each European candidate, the cost of data egress and a list of what has no equivalent at all.
Portable architecture
Kubernetes and infrastructure as code, with standard interfaces and the whole configuration in your repository. Nothing that only exists in a web console.
Phased migration
New environment, overlap, service-by-service move and cutover when it is confirmed. With a rollback plan at every phase, not only at the start.
What we hand over
The assessment report
Service by service: what you use, which European provider covers it and with what differences, what would have to be rebuilt, what it costs to get the data out and how much work each piece is. With a comparison of the candidates — Exoscale, STACKIT, OVHcloud and others depending on the case — on what actually affects you: regions, certifications, managed catalogue, networking and support.
The architecture
A documented design of the destination, with the Terraform code and the manifests that bring it up. Networking, storage, backups, identity, secrets, observability and deployment, written so they can be applied again at another provider.
The migration
In phases, at a fixed price calculated from the assessment. Both environments running side by side as long as needed, data moved in an agreed window, and cutover only once the destination has already been serving real traffic.
When it is NOT worth it
If your product rests on proprietary services with no equivalent and rebuilding them costs more than the problem you are solving; if you have a certification built on top of the current infrastructure; or if the spend is small enough that the migration never pays for itself. It goes in the report, and it is as valid a conclusion as the opposite one.
How we work
Inventory
What is deployed, which managed services are in use and how much configuration lives outside a repository.
Assessment and candidates
Equivalences, egress cost, a comparison of European providers and an effort estimate. This is where it is decided whether it goes ahead.
Architecture and new environment
Destination brought up with Terraform and Kubernetes, with backups, observability and deployment working before anything moves.
Move and cutover
Service by service, with overlap, real traffic at the destination and rollback available until the last moment.
Frequently asked questions
Do we have to leave entirely, or can we stop halfway?
You can, and often that is the sensible answer: move what has a clear equivalent and leave with the current provider what would cost more to rebuild than it saves. The assessment says which piece is in which group.
Does this make us «sovereign»?
It depends what you are being asked for. A European provider with European regions and a European legal entity satisfies a fair number of tender and contract requirements, but «sovereignty» means different things in different sectors. If you have the requirement in writing, we read it and say what the proposed architecture covers and what it does not.
Will we pay less?
Possibly, but that is not the main reason and we do not sell it as one. The cost comparison goes in the report against your own figures, including what it costs to operate the destination, which is the part usually forgotten.
Is Kubernetes mandatory?
No. It is the most common way to make a workload movable without rewriting it, but if what you have is a handful of machines and a database, putting Kubernetes in the middle adds a problem rather than removing one.
Do we have to change cloud provider to start?
No. Reliability work happens on what you already have, whether that is AWS, Azure, Google Cloud, a European provider or your own hardware. Migration is a separate service and only makes sense if there is a reason for it.
How long before we notice anything?
The noise goes first: an alert review usually shows results within the first few weeks, because a good share of what fires is not actionable. SLOs take longer, because they need measuring, and they are worth nothing until there are a few weeks of data behind them.
Do you sign a non-disclosure agreement?
Yes, if you want one, and nothing we see is used as an example anywhere without written permission. Access is requested at the minimum needed and documented.
Ask for the exit assessment
Tell us which provider you are on and which managed services you use. We reply within 24 working hours with the scope of the assessment and the timescale.
or write to us at info@esdis.es