Migrate from AWS or Azure to a European Cloud

A migration from AWS, Azure or Google Cloud to a European provider is a project with six stages: take inventory, map every service to an equivalent, rebuild the infrastructure with portable tooling, move the data, run both environments in parallel and then switch traffic. Most of the effort sits in the services that only exist at the hyperscaler. Virtual machines, containers and standard databases are rarely the problem.

Why companies move

The motives are usually a mix of cost, especially for outbound traffic, data protection and the wish to reduce dependency on a single non-European provider. Our page on sovereign cloud explains how data location and the provider’s legal seat differ. Whatever the reason, write down the goal before you start, because it decides which compromises are acceptable.

Step 1: Inventory

List everything that runs in your account, not only what you remember. Billing reports and the resource inventory of the provider are a good starting point. For each item record:

• what it does and who owns it,
• how much data it holds and how much traffic it produces,
• whether it is a standard technology (Linux VM, PostgreSQL, S3-style storage) or a proprietary service,
• which other services depend on it.

The result is a dependency map, and with it a realistic estimate of effort.

Step 2: Map services to equivalents

Typical AWS service	Portable equivalent at a European provider
EC2 virtual machines	Cloud servers or instances
S3	S3-compatible object storage (offered by most European providers)
RDS for PostgreSQL or MySQL	Managed database, or self-operated on a server
EKS	Managed Kubernetes
Elastic Load Balancing	Provider load balancer or an ingress controller
Route 53	Any DNS provider
Lambda, DynamoDB, SQS, Step Functions	Usually rework: containers, PostgreSQL, an open-source queue or a different design

Azure and Google Cloud follow the same logic. The bottom row is where you spend your time. Services like DynamoDB or Cosmos DB have no drop-in replacement, so plan code changes and testing.

To see which European provider offers which managed services, compare European cloud providers and, for the enterprise platforms, STACKIT, IONOS Cloud and OVHcloud.

Step 3: Rebuild with portable tooling

Do not recreate everything by hand in a new web console. Describe the target infrastructure as code with Terraform or OpenTofu; most European providers publish providers for these tools. Package applications as containers. If you already run Kubernetes, a managed Kubernetes service in Europe is the most direct target, because your manifests and Helm charts carry over with changes mainly in storage classes, load balancers and ingress.

If you do not need Kubernetes, do not introduce it just for the migration. A PaaS or Docker Compose on a few servers is often enough; see container deployment for small teams.

Step 4: Move the data

Data is the critical path. Options:

• Object storage: sync with an S3-compatible tool, then run a final delta sync during cutover.
• Databases: dump and restore for small databases; logical replication for larger ones, so the new database stays in sync until the switch.
• File systems and volumes: rsync or snapshot export, depending on the provider.

Egress costs. Moving large data volumes out of a hyperscaler used to be expensive. The EU Data Act requires cloud providers to reduce switching charges and to stop charging them entirely from 12 January 2027. In addition, AWS, Microsoft and Google have announced that customers who leave can have data transfer fees waived, usually after contacting support. Check the current conditions and apply before the large transfer.

Step 5: Parallel run and testing

Run the new environment alongside the old one. Test functionality, performance under realistic load, backups and restores, monitoring and alerting. Lower DNS TTLs a few days in advance so the switch takes effect quickly.

Step 6: Cutover and cleanup

Freeze writes or switch to the replicated database, run the final data sync, change DNS, watch error rates and keep the old environment ready for rollback for a defined period. Only then delete resources in the old account, and keep an export of logs and billing data you are obliged to retain.

Common pitfalls

• Hidden dependencies such as IAM roles, SES for email or CloudFront in front of a bucket.
• Underestimating operations work for services that were managed before.
• Licences tied to the hyperscaler’s marketplace.
• Contracts and compliance: sign the new provider’s data processing agreement and update your records of processing before production data moves.

This guide is general orientation, not legal advice. For personal data, involve your data protection officer, and check contract terms with both providers.