How to move your company's infrastructure to an EU cloud

Moving your company’s infrastructure from a US cloud provider like AWS, Google Cloud, Azure, or DigitalOcean to a European provider is a structured engineering project that usually takes a few weeks of preparation and a brief, planned cutover window. Instead of moving everything at once by hand, the safest approach follows six clear steps: auditing your current bill and resources, rebuilding the servers and networks on the new European cloud using infrastructure-as-code, setting up live data synchronization for your databases and files, pointing your existing deployment pipelines to the new servers, switching your domain names over during a short maintenance pause, and keeping the old environment running in reverse sync for a few weeks as a safety net. For standard web applications built on Linux servers, PostgreSQL or MySQL, Redis, Kubernetes, and S3-compatible storage, the transition is straightforward; only deeply proprietary cloud services require code changes before you move.

Key takeaways

Standard stacks move easily: If your application runs on virtual machines, containers, Kubernetes, PostgreSQL, MySQL, Redis, and S3-compatible object storage, you can move to a European cloud without rewriting your application code.
Proprietary services take extra work: Databases like AWS DynamoDB, Google Firestore, or Azure Cosmos DB do not have drop-in equivalents on European clouds and require migrating to an open-source database first.
You do not copy running applications: A good migration rebuilds clean infrastructure using code (like Terraform) and uses your existing CI/CD deployment pipeline to deploy your software to the new servers.
Data moves while you stay online: By using logical replication for databases and checksum-verified syncing for object storage, you copy the bulk of your data in the background while your business continues operating normally.
Switching fees are regulated: Under the EU Data Act, cloud providers can only pass on the actual direct cost of data egress when you switch providers, and all switching charges will be banned entirely starting January 12, 2027.

Why European companies are reconsidering where their infrastructure lives

For the past decade, defaulting to AWS, Google Cloud, or Microsoft Azure was the standard path for European startups and mid-sized companies. Today, many founders, CFOs, and engineering leads at 10-to-300-person companies are reviewing that decision for three practical reasons: cost predictability, regulatory compliance, and vendor independence.

First, US hyperscaler bills often grow faster than the underlying business. While basic compute instances have predictable prices, auxiliary charges for network egress, managed NAT gateways, cross-zone traffic, and proprietary database inputs/outputs frequently make up a large portion of the monthly invoice. European cloud providers generally offer simpler pricing models, often bundling generous or unmetered network traffic with their virtual servers and managed services.

Second, legal and compliance teams face ongoing friction around data jurisdiction. Many US clouds offer EU regions—and Amazon has launched the AWS European Sovereign Cloud, which keeps data and operations inside the European Union—but these entities ultimately belong to US parent corporations subject to US extraterritorial laws like the CLOUD Act. For companies selling to European public sector bodies, healthcare organizations, or regulated financial institutions, using a cloud provider headquartered and owned within Europe simplifies vendor risk assessments. Furthermore, for financial entities and their critical ICT providers, the Digital Operational Resilience Act (DORA), which took effect on January 17, 2025, explicitly requires documented exit strategies and tested plans to move away from critical third-party infrastructure providers.

Finally, the financial barrier to leaving a cloud provider has dropped. Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers are prohibited from imposing punitive egress fees when a customer switches to another provider. Until January 12, 2027, providers may charge no more than their actual, direct cost incurred for the data transfer, and from January 12, 2027 onward, switching charges—including data egress fees for switching—are banned completely. Importantly, major hyperscalers already offer specific fee-waiver programs if you notify their support teams before migrating off their platform.

Choosing the right European cloud provider

“EU cloud” is not a single category. Different European providers focus on different layers of the stack, ranging from raw, low-cost hardware to broad developer platforms. Choosing the right destination depends on which services your engineering team relies on today.

Provider	Headquarters	Managed PostgreSQL / MySQL	Managed Kubernetes	S3-Compatible Storage	Typical Best Fit
UpCloud	Finland	Yes	Yes	Yes	High-performance general workloads, balanced managed services, reliable support.
Scaleway	France	Yes	Yes	Yes	Cloud-native teams wanting AWS-like features (queues, serverless containers, IAM).
Hetzner	Germany	No (Self-hosted)	No (Self-hosted)	Yes	Cost-conscious teams comfortable managing databases and Kubernetes on Linux VMs.
OVHcloud	France	Yes	Yes	Yes	Large footprint, dedicated bare-metal servers mixed with public cloud services.
STACKIT / IONOS / Exoscale	Germany / Switzerland	Yes	Yes	Yes	Enterprises and DACH-region businesses with strict local compliance mandates.

If your team currently uses managed databases (like AWS RDS or Cloud SQL) and managed Kubernetes (like EKS or GKE), moving to UpCloud, Scaleway, or OVHcloud allows you to keep an equivalent operational model. If you choose Hetzner for its lower compute prices, your team—or your migration partner—will need to set up and maintain PostgreSQL, MySQL, or Kubernetes directly on virtual servers, including handling automated backups, patching, and failover.

What moves easily—and what requires engineering work

Before planning dates, you need an honest assessment of how tightly coupled your software is to your current provider. Cloud services generally fall into three migration buckets:

1. Direct equivalents (Low effort)

These components use open standards or open-source software under the hood. They can be recreated on a European cloud with no changes to your application code:

Virtual machines: Linux servers (EC2, Compute Engine, Droplets).
Relational databases: Managed PostgreSQL and MySQL/MariaDB.
Object storage: S3-compatible buckets (used for user uploads, backups, and static assets). Since European providers support the standard S3 API, you only need to change the endpoint URL and access keys in your application configuration.
Caches: Redis-compatible in-memory stores (moving to managed Valkey or Redis).
Containers and orchestration: Docker workloads running on standard Kubernetes clusters.
Networking: Private networks (VPCs), firewall rules (security groups), and standard HTTP/TCP load balancers.

2. Services needing light adaptation (Medium effort)

These components aren’t always standardized, so moving them requires updating configuration files, deployment scripts, or small wrapper modules in your code:

Message queues and pub/sub: Moving from AWS SQS or Google Pub/Sub to either Scaleway’s messaging services or a self-hosted/managed RabbitMQ, NATS, or Redis queue.
Serverless functions: AWS Lambda or Cloud Functions usually need to be packaged into lightweight containers or moved to a European provider’s serverless platform.
Transactional email and DNS: Moving from AWS SES or Route 53 to independent European or specialized providers, updating DNS records and API credentials.
CI/CD permissions: Updating GitHub Actions or GitLab CI pipelines to authenticate with the new cloud’s container registry and deployment targets instead of AWS IAM or Google Cloud IAM.

3. Proprietary lock-in services (High effort)

If your application relies heavily on proprietary databases or analytics engines, you cannot simply move them as-is. You must refactor that part of your application before or after the main infrastructure move:

Proprietary NoSQL: AWS DynamoDB, Google Firestore, and Azure Cosmos DB have unique APIs and data models. Moving off them requires rewriting your data access layer to use PostgreSQL (often using JSONB columns), MongoDB, or an open-source key-value store.
Cloud data warehouses: Amazon Redshift, Google BigQuery, and Azure Synapse require migrating schemas and SQL queries to an alternative like ClickHouse, PostgreSQL, or an independent data platform.

The 6-step migration process

A calm, predictable cloud migration does not involve freezing feature development for months or copying whole virtual hard drives across the internet. Instead, it separates building the environment, syncing the data, and switching the traffic into distinct steps.

Step 1: Audit and analyze

Start by reviewing your current cloud bill and granting read-only access to inspect your live cloud account. Billing invoices are useful because they reveal forgotten resources—like unattached storage volumes, old snapshots, or secondary regions—that engineers often overlook. Make a complete inventory of every server size, database version, storage bucket, network subnet, and firewall rule. At this stage, calculate your expected monthly bill on the target European cloud so management has a clear financial baseline.

Step 2: Rebuild the environment as code

Do not clone live virtual machines byte-for-byte. Old servers often carry configuration drift and outdated system packages. Instead, recreate your target infrastructure cleanly on the European cloud using Infrastructure as Code (such as Terraform or OpenTofu). Provision the virtual private networks, firewall rules, load balancers, empty managed databases, and empty object storage buckets to match the sizing and topology of your current setup.

Step 3: Synchronize the data live

Moving gigabytes or terabytes of data takes time, so it must happen while your existing system remains live and serving customers.

For object storage: Use synchronization tools that copy files from your old buckets to the new European buckets and verify every file using cryptographic checksums. Run an initial bulk sync, followed by periodic incremental syncs to catch newly uploaded files.
For databases: Set up logical replication between your old database (the source) and your new European database (the destination). In plain English, logical replication first takes a consistent snapshot of your existing tables and copies them over; once that finishes, it continuously streams every new INSERT, UPDATE, and DELETE from the old database to the new one in real time.

Step 4: Point your deployment pipelines

With the new servers running and the data syncing, work with your engineering team to update your CI/CD pipelines (such as GitHub Actions or GitLab CI). Add a new deployment target so that your exact same application code and container images are deployed to the European environment alongside your current production environment. Update environment variables on the new servers to point to the new database endpoints, Redis instances, and object storage URLs. You can now test the new environment thoroughly using internal domain names without affecting live users.

Step 5: Execute the cutover switch

A few days before the switch, lower the TTL (Time-To-Live) on your DNS records to 60 or 300 seconds so that internet routers do not cache your old IP addresses for long.

Wait until your database replication lag is consistently under 5 seconds and all automated health checks on the new environment pass. During a pre-announced, low-traffic maintenance window, follow a strict checklist:

Put your application into a brief read-only or maintenance mode (pausing new database writes).
Verify that replication lag has reached zero—meaning every last transaction from the old cloud is now present in the European database.
Run a final delta sync on object storage buckets.
Promote the European database to be the primary standalone database.
Enable writes on the new European application environment.
Update your DNS records (or proxy targets in Cloudflare/similar) to point live user traffic to the new European load balancers.

For most standard web applications, the actual write pause during this switch lasts only a few minutes.

Step 6: Keep a rollback path, then clean up

Never delete your old cloud environment the day after a migration. If an unexpected edge case appears three days later, you want a safe way back. By configuring reverse replication—streaming new database changes from the European cloud back to the old cloud—you keep the old environment warm and up to date. Keep this reverse sync running for 30 days. Once your team is completely confident in the stability and performance of the new setup, stop the sync, take final archival snapshots if required by your compliance policies, and shut down the old cloud resources so you stop paying for them.

Common pitfalls to avoid

Forgetting outbound IP allowlists: If your application connects to third-party partners (like payment gateways, banking APIs, or enterprise customer systems) that restrict access by IP address, give those partners your new European egress IP addresses well in advance of the cutover.
SSL certificate rate limits: Make sure your new load balancers or ingress controllers can issue TLS/SSL certificates (for example, via Let’s Encrypt HTTP or DNS challenges) before you switch live traffic, so users do not see browser security warnings during DNS propagation.
Hardcoded region assumptions: Search your codebase for hardcoded AWS region strings (like eu-central-1 or amazonaws.com) in file upload validators, Content Security Policy (CSP) headers, or image-processing workers.
Ignoring email deliverability: If you send emails directly from your servers or move transactional email providers at the same time, ensure SPF, DKIM, and DMARC records are updated so password resets and invoices do not land in spam folders.

Frequently asked questions

Will our customers experience downtime during the move?

To avoid losing data when moving a relational database across two different cloud providers, you need a short planned pause on database writes during the final cutover. Because the bulk of the data is already synchronized in advance via logical replication, this maintenance window usually takes only a few minutes and can be scheduled during your quietest night or weekend hours.

How much will we save by moving to an EU cloud?

Savings vary depending on your workload, as hyperscalers and European providers price resources differently. Generally, raw compute, memory, managed databases, and especially outbound network bandwidth have lower list prices on providers like Hetzner, UpCloud, OVHcloud, and Scaleway compared to AWS, GCP, or Azure as of 2026. The most accurate way to know is to map your current resource inventory against the public pricing pages of your chosen European provider.

What if we use AWS DynamoDB or Google BigQuery?

Because European clouds do not offer drop-in clones of proprietary services like DynamoDB or BigQuery, you have two choices. You can either migrate those specific data stores to open-source alternatives (like PostgreSQL or ClickHouse) before moving your infrastructure, or you can move your main compute and standard databases to the EU cloud first while temporarily keeping the proprietary service where it is until your team refactors it.

Do we have to pay high data egress fees to leave AWS, GCP, or Azure?

No. Under Article 29 of the EU Data Act, providers cannot charge more than their direct cost for switching egress today, and all switching fees are banned from January 12, 2027. Most major US hyperscalers already provide a formal process to request credits or waivers for data transfer fees when you are permanently migrating workloads off their platform—just make sure to open that request with their support team before you start syncing large volumes of data.

How MoveInfra can help

MoveInfra handles this entire 6-step migration process for companies moving from AWS, Google Cloud, Azure, or DigitalOcean to European clouds like UpCloud, Scaleway, Hetzner, and OVHcloud. You can start by uploading your current cloud bill for a free analysis and fixed-price quote with no account access required. From there, MoveInfra rebuilds your infrastructure in Terraform, manages live database and storage replication, helps your team point your CI/CD pipelines to the new environment, and maintains a 30-day reverse-replication rollback window after the switch.