How do you migrate from a US hyperscaler to a European cloud?
Migrating from a US hyperscaler to a European or sovereign cloud is a mapping exercise: list every managed service you use, map each one to an equivalent from the new provider or to an open-source service you run yourself, move the data, run both environments in parallel and switch traffic over. Containers on Kubernetes move with little change. Managed databases, queues, identity, and proprietary AI, analytics and serverless services are where the work and the capability gaps sit.
Step 1: inventory what you actually use
Start from the bill and the infrastructure code, not from architecture diagrams. Group every service into one of three buckets:
- Commodity: virtual machines, Kubernetes, block storage, load balancers, S3-compatible object storage. Most European providers offer these.
- Portable with work: managed PostgreSQL or MySQL, Redis, Kafka or queues, KMS, DNS, container registry. Open-source equivalents exist and run on Kubernetes.
- Proprietary: serverless functions tied to provider events, proprietary NoSQL databases, data warehouses, managed AI services. These have no drop-in replacement.
Include the services teams forget: IAM roles used by workloads, monitoring and log pipelines, CI runners, email sending, secrets stores and backup tooling.
Step 2: map each service
| Category | Portable target | What to check |
|---|---|---|
| Kubernetes (EKS, AKS, GKE) | Any CNCF Certified Kubernetes service or distribution | Provider-specific annotations on load balancers, storage classes and ingress |
| Relational databases | The new provider’s managed database, or an operator such as CloudNativePG | Extensions, version, point-in-time recovery, replica topology |
| Object storage | S3-compatible storage from the new provider, or a self-hosted alternative | Which S3 features you use: event notifications, lifecycle rules, object lock, presigned URLs |
| Queues and streaming | Kafka (for example with the Strimzi operator), RabbitMQ or NATS | Ordering and delivery guarantees, retention, consumer offsets |
| Secrets and keys | The new provider’s KMS, OpenBao or HashiCorp Vault, plus the External Secrets Operator | Key rotation, HSM backing, audit logs |
| Workload identity | OIDC-based federation from the cluster to each cloud API | Every place a static key is used today |
| Serverless, NoSQL, analytics, AI | Rewrite on open-source components, keep on the old provider, or accept a reduced feature set | Cost of rewriting versus the risk of keeping the dependency |
The CloudNativePG tutorial shows the database step in practice, and how Kubernetes workloads access cloud APIs without static keys covers identity. Be explicit with stakeholders about the last row: some managed AI and analytics services have no European equivalent with the same features, and a hybrid setup is a valid outcome.
Step 3: keep Kubernetes as the constant layer
If your applications already run on Kubernetes, the Deployments, Services, Helm charts and CI pipelines can stay the same. Changes are limited to the edges: storage classes, load balancer annotations, ingress controllers and the identity setup. Teams that want a gradual move often run one control plane with nodes in both the old and the new cloud for a transition period; whether one Kubernetes cluster can span multiple clouds discusses the trade-offs.
Step 4: move the data
Data transfer is the slowest and most expensive step:
- Databases: use logical or streaming replication to the new site and switch when the lag is near zero. Dump and restore only for small databases or ones that can take downtime.
- Object storage: copy buckets with a sync tool such as rclone, then run a final incremental sync before the cutover.
- Volumes: restore from backups made with a tool such as Velero, or replicate at the application level.
Egress from hyperscalers is billed per gigabyte; see what are cloud egress fees. Under the EU Data Act, providers may charge only cost-based switching fees, including data egress, until 12 January 2027, and none after that date. The Data Act also sets notice and transition periods that you can invoke with the old provider.
Step 5: run in parallel and cut over
- Lower DNS TTLs a few days before the switch.
- Deploy the full stack in the new environment and run it against replicated data.
- Mirror or replay a share of production traffic and compare results.
- Switch DNS or the global load balancer, and keep the old environment ready for rollback for a fixed period.
- Decommission the old resources, then delete the data and request the provider’s deletion confirmation.
Plan the exit before you commit
The new provider is also a provider you may leave one day. Before signing, check that you can export data in standard formats, that you hold your own backups outside the provider, and that your infrastructure code does not depend on proprietary APIs where an open alternative exists. Test a restore on a different provider at least once. The guide to cloud sovereignty, data residency and portability lists European providers and portability principles, and how to avoid cloud vendor lock-in covers the general strategy.
Migrating with Cloudfleet
Cloudfleet runs CNCF-conformant Kubernetes, so applications can move to or from other standard Kubernetes environments without code refactoring, as described in What is Cloudfleet. One cluster can combine node auto-provisioning on AWS, GCP and Hetzner Cloud with self-managed nodes on other European providers or on-premises, which lets workloads move from one provider to another inside the same cluster.