Moving from DigitalOcean to a European cloud provider like UpCloud, Scaleway, or Hetzner is one of the most straightforward infrastructure projects a small engineering team can undertake. Unlike the big US hyperscalers, DigitalOcean is built around standard, open-source primitives: Linux virtual machines, standard PostgreSQL and MySQL databases, S3-compatible object storage, and upstream Kubernetes. Because your applications are rarely tied to proprietary APIs, you do not need to rewrite your software to leave. You can replicate your setup on an EU-owned provider, synchronize your data over the network, and switch your traffic over a single planned maintenance window.

Key takeaways

• Low technical lock-in: DigitalOcean Droplets, Managed Databases, and Spaces map directly to standard services on European clouds without code changes.
• Three distinct EU targets: UpCloud offers a very similar developer experience with high-performance storage; Scaleway provides the broadest ecosystem of managed services and serverless tools; Hetzner delivers the lowest compute prices if you are willing to manage databases and Kubernetes yourself.
• App Platform requires a choice: If you use DigitalOcean App Platform, you will either move to Scaleway Serverless Containers or transition to a standard container setup using Docker or Kubernetes.
• Egress costs are manageable: Most DigitalOcean plans include a generous outbound data transfer pool, and under the EU Data Act, switching egress fees are capped at provider cost until January 12, 2027, when they are banned entirely.

Why leaving DigitalOcean is simpler than leaving a hyperscaler

When companies migrate away from AWS, Google Cloud, or Azure, they spend most of their time untangling proprietary services. An application built on AWS often relies on IAM roles for internal authentication, DynamoDB for data storage, SQS for queuing, and Lambda for compute. Moving that application requires rewriting code and redesigning how services talk to each other.

DigitalOcean was designed differently. It became popular with startups and small teams specifically because it avoided that complexity. When you deploy on DigitalOcean, you are usually using standard Linux virtual machines (Droplets), standard open-source databases (PostgreSQL, MySQL, Redis/Valkey), an S3-compatible object store (Spaces), and standard Kubernetes (DOKS).

For a European company looking to bring its infrastructure under EU jurisdiction, this architecture is an advantage. Your application code speaks standard protocols: TCP/IP, SQL, Redis protocol, and the S3 HTTP API. European cloud providers speak these exact same protocols.

Instead of an application refactoring project, a move from DigitalOcean to Europe is a pure infrastructure migration. You build an equivalent environment on the new provider, copy your data, update your deployment pipelines, and switch your DNS records.

Choosing your destination: UpCloud, Scaleway, or Hetzner

European cloud infrastructure has matured significantly. For teams leaving DigitalOcean, three providers stand out depending on your budget, your reliance on managed services, and how much operations work your team wants to do.

UpCloud: the closest match for DigitalOcean teams

Headquartered in Finland, UpCloud is built for small and mid-sized engineering teams that want high reliability, predictable Euro billing, and a clean control panel without dozens of obscure services.

If your DigitalOcean setup consists of Droplets, Managed PostgreSQL or MySQL, Managed Redis/Valkey, Load Balancers, Managed Kubernetes, and Spaces, UpCloud has a direct one-to-one equivalent for every component. UpCloud is also well-known for its in-house MaxIOPS block storage, which offers noticeably faster disk read and write speeds than standard shared VPS storage.

For pricing, UpCloud offers entry-level Starter plans starting at approximately €3 per month for 1 vCPU and 1 GB of RAM as of 2026, alongside Cloud Native and High Performance tiers (check UpCloud's pricing page for current specifications and regional availability). UpCloud also includes zero-cost data egress under a fair transfer policy across its plans.

Scaleway: the broadest managed ecosystem

Based in France and part of the Iliad Group, Scaleway is the closest European equivalent to a full-featured cloud platform. Like UpCloud, it covers all the core DigitalOcean primitives: Virtual Instances, Managed Databases for PostgreSQL and MySQL, Managed Redis, Kubernetes Kapsule, Load Balancers, and S3-compatible Object Storage.

Scaleway stands out if your team uses higher-level platform services. If you rely on DigitalOcean Functions or DigitalOcean App Platform, Scaleway offers Serverless Functions, Serverless Containers, and Serverless Jobs. It also provides managed messaging and queuing systems, transactional email (TEM), and an integrated observability platform (Cockpit). If your team wants to minimize server maintenance and rely on managed platform tools, Scaleway is the strongest fit.

Hetzner: maximum compute value for hands-on teams

Based in Germany with data centers in Germany and Finland, Hetzner is famous across Europe for its price-to-performance ratio. If your primary goal is reducing your monthly infrastructure bill while keeping data in the EU, Hetzner is hard to beat.

However, there is a clear trade-off: Hetzner focuses strictly on core infrastructure. It provides Cloud Servers (VMs), Block Storage Volumes, Private Networks, Firewalls, Load Balancers, and S3-compatible Object Storage. Hetzner does not offer managed databases, managed Redis, or managed Kubernetes.

If you move from DigitalOcean to Hetzner, any managed PostgreSQL clusters or DOKS (Kubernetes) clusters you currently run will need to be set up and maintained on Linux virtual machines. For teams with experienced DevOps or platform engineers, running PostgreSQL with automated backups or deploying a lightweight Kubernetes distribution (like k3s) on Hetzner VMs is routine. For teams without dedicated operations staff, the money saved on compute can easily be lost in engineering time spent managing database failovers and cluster upgrades.

Service-by-service mapping

The table below shows how DigitalOcean products map to UpCloud, Scaleway, and Hetzner.

What about pricing and switching costs?

Small teams often choose DigitalOcean for its predictable monthly pricing, where shared CPU Droplets start at approximately $4 to $7 per month and Spaces starts at a $5 per month base subscription as of 2026 (always check the provider's official pricing page for current rates).

When moving to an EU cloud, you gain two financial benefits:

1. Billing in Euros: For European companies, paying in USD introduces foreign exchange fees and monthly accounting variance. UpCloud, Scaleway, and Hetzner all bill natively in Euros.
2. Lower or comparable resource costs: European providers are generally priced very competitively against US counterparts. Hetzner in particular often reduces raw compute and storage bills substantially, while UpCloud and Scaleway offer comparable or better performance per Euro spent, especially when factoring in network transfer.

Egress fees and the EU Data Act

During a migration, you have to copy your databases and object storage over the internet to the new cloud provider. On some clouds, this outbound data transfer (egress) causes a painful final bill.

On DigitalOcean, this is rarely an issue for small and mid-sized teams. Droplets and Spaces plans include generous monthly outbound transfer allowances pooled across your account. Unless you are moving many terabytes of media files in a single month, your migration traffic will likely fit inside your existing included bandwidth pool.

Furthermore, European law protects companies switching cloud providers. Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers may not charge switching fees—including data egress charges incurred to move to another provider—above their actual direct cost, and from January 12, 2027, all switching charges and switching egress fees are banned entirely across the EU.

How to execute the migration: a 6-step checklist

If you decide to move your DigitalOcean environment to UpCloud, Scaleway, or Hetzner, you do not need a six-month roadmap. Most small teams can complete the preparation in a few days and execute the switch during a quiet evening window.

1. Inventory your DigitalOcean account

• List all active Droplets, their CPU/RAM sizes, and any local data stored on their disks (outside of databases).
• Check your Managed Databases: note the exact engine version (for example, PostgreSQL 15 or MySQL 8), database size, and extensions used.
• Check Spaces buckets: note total storage size, public vs. private access permissions (ACLs), and whether you use the built-in Spaces CDN.
• Document all Cloud Firewall rules, VPC subnet ranges, and Load Balancer health check settings.
• Lower the TTL (Time-To-Live) on your DNS records to 60 or 300 seconds a few days before the cutover.

2. Provision the EU target environment as code

• Even if you created your DigitalOcean resources by clicking around in the web console, use the migration as an opportunity to write Terraform (or OpenTofu) configurations for your new EU cloud. UpCloud, Scaleway, and Hetzner all maintain official, well-documented Terraform providers.
• Create the private network, firewall rules, virtual machines, load balancers, and database clusters in your chosen EU region (such as Frankfurt, Amsterdam, Paris, Warsaw, or Helsinki).
• Do not copy old virtual machine disk snapshots directly unless necessary. Instead, provision fresh Linux VMs on the EU cloud and deploy your application code to them.

3. Synchronize your object storage

• Create the corresponding buckets on UpCloud, Scaleway, or Hetzner Object Storage.
• Use a tool like rclone configured with both your DigitalOcean Spaces keys and your new EU S3 keys.
• Run an initial background sync (rclone sync with checksum verification). Because this runs while your live application is still on DigitalOcean, it can take several hours or days without affecting users.
• Just before cutover, you will run a final delta sync to catch any newly uploaded files.

4. Set up live database replication

• Rather than taking your app offline for hours to run pg_dump and pg_restore, use logical replication (for PostgreSQL) or binary log replication (for MySQL).
• Configure your new EU database to subscribe to changes from your DigitalOcean Managed Database over an encrypted connection, restricting access by IP address in your DigitalOcean database firewall.
• Let the initial data copy complete, and verify that replication lag drops to near zero. Your EU database is now a live, up-to-date follower of your DigitalOcean database.

5. Point your CI/CD pipelines and test

• Update your GitHub Actions, GitLab CI, or deployment scripts to deploy your application containers or binaries to the new EU servers or Kubernetes cluster.
• Update your application's environment variables in the new environment so it points to the new EU database, the new Redis cache, and the new S3 object storage endpoints.
• Test the new environment thoroughly using internal host file overrides or a staging domain before exposing it to public traffic.

6. Cut over traffic and keep a rollback path

• Choose a low-traffic window for your users.
• Put your application into a brief maintenance or read-only mode (so no new writes hit the DigitalOcean database).
• Verify that database replication lag is zero and run a final fast rclone pass on your object storage.
• Promote the EU database to be the primary writer.
• Update your DNS records (or proxy targets in Cloudflare/bunny.net) to point to the new EU Load Balancer IP address.
• Keep the old DigitalOcean environment running for a week or two (ideally with reverse replication configured if you need a fast rollback option) before deleting the old resources and closing out your bill.

Common pitfalls to watch out for

Even in a simple migration, a few details can catch teams by surprise:

• Hardcoded Spaces URLs: DigitalOcean Spaces URLs follow the pattern bucket.region.digitaloceanspaces.com (or cdn.digitaloceanspaces.com). If you stored full URLs in your database rows instead of relative paths, you will need to run a database migration script to update those strings, or use a custom domain for your object storage so the URL never changes again.
• Droplet metadata service: If your custom boot scripts query the DigitalOcean metadata IP (169.254.169.254) using DigitalOcean-specific JSON paths, you may need to adjust them to standard cloud-init formats used by UpCloud, Scaleway, and Hetzner.
• Database connection pools: DigitalOcean Managed Databases include built-in PgBouncer connection pooling configured in the control panel. Check how your target provider handles connection pooling (UpCloud and Scaleway offer managed pooling options, while on Hetzner you will need to install PgBouncer alongside PostgreSQL).
• SMTP port blocking: To prevent spam, DigitalOcean, UpCloud, Scaleway, and Hetzner all frequently block outbound ports 25, 465, and 587 by default on new accounts. If your servers send email directly or connect to an SMTP relay over those ports, request port unblocking from support before your migration night, or switch to an HTTP API or port 2525.

Frequently asked questions

Will moving from DigitalOcean to an EU cloud require downtime?

Most migrations require a short, planned write pause during the final cutover. Because your database and object storage are synchronized in the background while your app stays live, the actual cutover only requires pausing database writes, confirming replication lag is under a few seconds, promoting the new database, and switching DNS. For most small teams, this write pause takes between a few seconds and a few minutes.

How do we migrate DigitalOcean App Platform?

DigitalOcean App Platform is a Platform-as-a-Service (PaaS) that builds and runs code from your Git repository. If your app uses a Dockerfile, the easiest managed equivalent in Europe is Scaleway Serverless Containers. Alternatively, if you move to UpCloud or Hetzner, you can deploy your containers onto a Managed Kubernetes cluster (UpCloud) or use a lightweight deployment tool like Kamal, Docker Compose, or Coolify on a virtual machine.

Can we keep Cloudflare in front of our new EU infrastructure?

Yes, and doing so actually makes the cutover faster. If you proxy your traffic through Cloudflare (or a European alternative like bunny.net), you do not have to wait for global DNS caches to expire during the switch. When you change the origin IP address in your proxy dashboard from your DigitalOcean Load Balancer to your new EU Load Balancer, traffic shifts to the new environment almost immediately.

Which provider is best if we need GDPR and DORA compliance?

UpCloud, Scaleway, and Hetzner are all headquartered in the European Union (Finland, France, and Germany respectively) and operate EU data centers under European jurisdiction, avoiding US extraterritorial laws that apply to US-owned providers like DigitalOcean. If your company falls under the EU Digital Operational Resilience Act (DORA, which applied from January 17, 2025), moving to standard open-source infrastructure defined in Terraform also satisfies key requirements for documented ICT exit strategies and reduced vendor lock-in.

How MoveInfra can help

If your team wants to move off DigitalOcean without pulling engineers away from product work, MoveInfra handles the migration end-to-end for a fixed price. We analyze your current setup, rebuild your environment as clean Terraform code on UpCloud, Scaleway, or Hetzner, synchronize your databases and Spaces buckets with live replication, and coordinate the cutover with a 30-day rollback window. You can upload your cloud bill on moveinfra.eu to get a free inventory and compare your new monthly costs before granting any access.

Sources

• Regulation (EU) 2023/2854 (EU Data Act) on EUR-Lex
• Regulation (EU) 2022/2554 (Digital Operational Resilience Act / DORA) on EUR-Lex
• DigitalOcean Pricing Overview
• UpCloud Pricing and Plans
• Scaleway Cloud Pricing
• Hetzner Cloud Overview and Pricing

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

Moving from Microsoft Azure to an EU-owned cloud requires rebuilding your compute and network configurations as code, replicating relational databases in real time, and shifting storage calls from Azure's proprietary APIs to standard S3-compatible endpoints. For most European software companies running Linux virtual machines, Kubernetes, PostgreSQL, and object storage, the migration takes a few weeks of preparation and a cutover pause of a few minutes. The main technical hurdles are decoupling Microsoft Entra ID from infrastructure access, swapping out the Azure Blob Storage SDK, and replacing proprietary services like Azure Service Bus or Cosmos DB with open-source equivalents.

Key takeaways

• Standard workloads move cleanly: Linux VMs, Azure Kubernetes Service (AKS), and Azure Database for PostgreSQL or MySQL map directly to EU providers like UpCloud, Scaleway, OVHcloud, and STACKIT.
• Object storage requires a code change: Unlike AWS and most European clouds that use the S3 API, Azure Blob Storage uses its own REST interface. You will need to update your application's storage client or use an S3-compatible abstraction library.
• Egress fees are disappearing: Under Article 29 of the EU Data Act, cloud providers can charge no more than their direct cost for switching egress until January 12, 2027, when switching fees are banned outright. Microsoft also offers a free egress credit program when you close your Azure subscriptions.
• Microsoft 365 can stay where it is: Moving production servers and customer databases to a European cloud does not mean you have to abandon Entra ID for employee single sign-on or Microsoft 365 for email.
• Rollback keeps the cutover safe: By using logical database replication, you can sync changes back to Azure after the DNS switch, preserving a clean fallback option while your team verifies the new environment.

Why European companies are reconsidering Azure

Many European organizations adopted Azure because they already used Windows Server, Active Directory, or Office 365. Over time, however, the infrastructure footprint often grows into a standard Linux and open-source stack that does not depend on Microsoft software, while the bill and compliance questions continue to grow.

Three practical reasons drive teams to move production workloads from Azure to an EU-owned cloud:

1. Jurisdiction and sovereignty: Even when you select Azure regions in Frankfurt, Amsterdam, or Dublin, Microsoft Corporation remains a US-headquartered company subject to US extraterritorial laws such as the CLOUD Act. For companies serving public sector clients, healthcare, or regulated financial institutions, hosting on an EU-headquartered provider removes this legal conflict.
2. Exit strategy mandates: The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), which has applied since January 17, 2025, requires financial entities and their critical ICT providers to maintain tested exit strategies and avoid concentration risk with hyperscalers.
3. Predictable billing: Azure pricing involves complex tiers of vCPUs, Storage Transaction Units, Virtual Network peering fees, NAT Gateway processing charges, and outbound bandwidth tiers. European providers generally bundle network traffic or charge flat monthly rates for compute and storage.

Mapping your Azure stack to EU cloud equivalents

Before moving any data, you need an accurate inventory of every resource group in your Azure subscriptions. Most architectures fall into three categories: components that translate directly, components that need minor code or configuration adjustments, and proprietary services that require architectural changes.

Note on Hetzner: Hetzner provides cost-effective virtual and dedicated servers, load balancers, networks, and S3-compatible object storage, but it does not offer managed databases or managed Kubernetes. When migrating to Hetzner, those services must be deployed and maintained on virtual machines.

Four Azure-specific friction points (and how to handle them)

Moving off Azure is slightly different from moving off AWS or Google Cloud because of how Microsoft couples identity, storage, and enterprise software.

1. Replacing the Azure Blob Storage SDK with S3

Every major European cloud provider builds its object storage around the Amazon S3 API standard. Azure Blob Storage uses a different structure (Storage Accounts, Containers, and Blobs) and its own SDK (@azure/storage-blob in Node.js, azure-storage-blob in Python, Azure.Storage.Blobs in .NET).

To migrate, you must update the storage layer in your application code to use a standard S3 client library (such as boto3 for Python or the AWS SDK for .NET configured with a custom endpoint URL). If your application generates Shared Access Signature (SAS) URLs so users can upload or download files directly, you will replace that logic with S3 presigned URLs. They work the same way and take only a few lines of code, but you must account for this change in your sprint planning.

For the files themselves, open-source tools like rclone talk natively to both Azure Blob Storage and S3-compatible targets, verifying cryptographic checksums on every transferred file.

2. Untangling Microsoft Entra ID (formerly Azure AD)

Teams often worry that leaving Azure means rebuilding their company's entire identity setup. You need to separate two distinct uses of Entra ID:

• Employee and customer authentication: If your back-office tools or web apps use Entra ID via OpenID Connect (OIDC) or SAML, nothing needs to change. OIDC works over the public internet regardless of where your servers live.
• Infrastructure Managed Identities: If your Azure VMs or AKS pods use Azure Managed Identities to authenticate to databases or storage without passwords, you will need to replace this mechanism. On an EU cloud, you typically move to Kubernetes secrets, HashiCorp Vault, database username/password authentication over private networks, or scoped S3 access keys.

3. Dealing with .NET, Windows, and SQL Server

If your company writes applications in modern .NET (.NET 6, 8, or newer), your code runs natively on Linux containers and Linux VMs. Moving a modern C# application to a European Kubernetes cluster or Linux server is no different from moving a Go, Node.js, or Python app.

However, if you rely on legacy .NET Framework (4.8 and older) on Windows Server, or if your application depends heavily on Azure SQL Database (Microsoft SQL Server), the migration requires more planning. While some European providers offer Windows Server licensing, many engineering teams use an infrastructure move as the moment to migrate schemas from SQL Server to PostgreSQL using tools like pgloader, eliminating Microsoft licensing fees altogether.

4. Rebuilding ARM or Bicep into Terraform

If your infrastructure is defined using Azure Resource Manager (ARM) templates or Bicep, those files cannot be reused on another cloud. Even if you already use Terraform or OpenTofu, the azurerm provider blocks must be rewritten using the provider plugin of your chosen European cloud (such as upcloud, scaleway, or ovh). Treating the migration as a clean rebuild in Terraform gives you an auditable, documented environment from day one.

Egress fees and your legal rights under the EU Data Act

Historically, cloud providers charged steep outbound data transfer fees (around $0.08 to $0.087 per GB on Azure after the first 100 GB per month, as of 2026) when you copied terabytes of backups and object storage over the internet.

In the European Union, Regulation (EU) 2023/2854 (the EU Data Act) changes the rules for switching data processing services:

• Transitional cap (until January 12, 2027): Providers may charge switching fees, including data egress fees incurred while moving to another provider, at no more than the direct cost incurred to perform the switch.
• Full ban (from January 12, 2027): Switching charges and data egress fees for switching between cloud providers are banned completely for EU customers.

Following the introduction of the Data Act, Microsoft introduced two policies you can use today (check Microsoft's official documentation and bandwidth pricing pages for current terms as of 2026):

1. Free egress when leaving Azure: Microsoft offers credits to cover internet data egress over 100 GB/month when you are migrating all data off Azure to another cloud provider. To qualify, you must open an Azure Support ticket before starting the transfer, follow their instructions, and cancel the associated Azure subscriptions once the migration is complete.
2. At-cost egress for parallel multi-cloud use: For EEA, EFTA, and UK customers running workloads across Azure and another provider in parallel, Azure offers reduced, at-cost data transfer rates upon submitting a support request with the destination provider's Autonomous System Number (ASN).

Step-by-step migration checklist

A reliable cloud migration avoids copying messy, years-old virtual disks. Instead, rebuild the infrastructure cleanly, stream the data across, and deploy fresh application artifacts from your existing pipeline.

• 1. Audit and right-size: Export your Azure Cost Management billing data and list every active resource. Identify idle VMs, unattached Managed Disks, and oversized databases so you only pay for what you actually use on the new cloud.
• 2. Refactor storage calls: Update application code that speaks directly to the Azure Blob Storage API so it supports standard S3 endpoints and presigned URLs.
• 3. Write the target infrastructure as code: Define your new private networks, firewall rules, load balancers, Kubernetes clusters, and managed database instances in Terraform on your target EU cloud.
• 4. Establish database replication: Set up a secure VPN or WireGuard tunnel between your Azure Virtual Network and the new EU cloud private network. Configure PostgreSQL logical replication (CREATE PUBLICATION on Azure, CREATE SUBSCRIPTION on the target) or MySQL binlog replication so the new database catches up and stays in live sync.
• 5. Clone object storage: Run rclone sync from a worker node to copy all containers from Azure Blob Storage into your new S3 buckets. Re-run periodically to sync newly uploaded files.
• 6. Point CI/CD to the new environment: Update your GitHub Actions, GitLab CI, or Azure DevOps pipelines to deploy your containers or application binaries to the new EU servers. Test the staging environment thoroughly.
• 7. Execute the cutover: Lower your DNS TTLs 24 hours in advance. During a scheduled low-traffic window, put the application in brief maintenance mode (pausing writes), run a final incremental rclone pass, verify that database replication lag is zero, promote the EU database to primary, and update your DNS records.
• 8. Maintain reverse replication before cleanup: Configure replication from your new EU primary database back to the old Azure database for 30 days. Once you are confident in the new setup, cancel the Azure subscriptions and claim any applicable egress credits.

Frequently asked questions

Can we keep using GitHub Actions or Azure DevOps if we move our servers to an EU cloud?

Yes. Your CI/CD runners only need network access or API credentials to deploy to your new servers or Kubernetes cluster. Many European teams keep their source code and pipelines on GitHub or Azure DevOps while moving production compute and customer databases to an EU provider.

How much downtime is required to switch from Azure Database for PostgreSQL?

Because PostgreSQL logical replication syncs data continuously in the background while your application stays online, you do not have to wait for a multi-hour dump and restore during cutover. Once replication lag is under a few seconds, you only need a short planned write pause—typically a few minutes—to let the last transactions flush, verify data consistency, and switch your application traffic.

What if we use Azure Kubernetes Service (AKS)?

Kubernetes is one of the easiest workloads to move. Standard Deployment, Service, and Ingress manifests work across any certified Kubernetes cluster. You will mainly need to change Azure-specific storage class names (for example, changing managed-csi to the CSI driver of UpCloud, Scaleway, or OVHcloud) and replace any Azure Key Vault CSI drivers with standard Kubernetes secrets or external secret operators.

Is Microsoft's EU Data Boundary enough for European sovereignty?

Microsoft's EU Data Boundary stores and processes customer data within European data centers, which helps with data residency requirements. However, data residency is different from legal jurisdiction. Because Microsoft is a US company, European residency does not insulate infrastructure from US legal jurisdiction in the same way that contracting with a wholly EU-owned cloud provider does.

How MoveInfra can help

If your team wants to move off Azure without pulling engineers away from product work for months, MoveInfra handles the migration end-to-end for a fixed price. We analyze your current Azure setup, rebuild your environment as clean Terraform code on an EU-owned cloud (such as UpCloud, Scaleway, OVHcloud, or Hetzner), keep your databases and object storage in live sync, and help your team switch over with a 30-day reverse-replication rollback window. Upload your cloud bill at moveinfra.eu for a free assessment of what can move automatically and what your new monthly infrastructure cost will look like.

Sources

• Regulation (EU) 2023/2854 of the European Parliament and of the Council (EU Data Act) - EUR-Lex
• Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) - EUR-Lex
• Bandwidth Pricing and Internet Egress FAQ - Microsoft Azure
• Azure Data Transfer Fees and European At-Cost Transfer - Microsoft Learn
• Logical Replication in Azure Database for PostgreSQL Flexible Server - Microsoft Learn

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

Leaving Google Cloud (GCP) for an EU-owned cloud provider is a straightforward process when your architecture relies on open standards like Linux virtual machines, PostgreSQL, Kubernetes, and S3-compatible object storage. By building parallel infrastructure as code on a European provider—such as UpCloud, Scaleway, OVHcloud, or Hetzner—and using logical replication to sync databases in real time, a typical 10-to-300-person company can switch production traffic during a short planned write pause of just a few minutes. The main obstacles are not servers or relational databases, but proprietary Google services like Firestore, Cloud Spanner, BigQuery, and IAM-coupled serverless workflows, which require code changes or architectural decisions before you move.

Key takeaways

• Standard workloads map cleanly: Compute Engine, GKE, Cloud SQL, Memorystore, and Cloud Storage have direct equivalents on EU-owned clouds like UpCloud, Scaleway, OVHcloud, and Exoscale.
• Proprietary services require a strategy: BigQuery, Firestore, and Pub/Sub do not have drop-in equivalents everywhere; you must decide whether to refactor them to open-source tools or keep BigQuery as an isolated analytics service.
• Egress fees are avoidable: Under the EU Data Act (Article 29), switching charges are capped at cost until January 12, 2027, and banned entirely after that date. Google Cloud also offers a formal exit program that waives data transfer fees when shutting down services.
• Parallel runs reduce cutover risk: Rebuilding your environment in Terraform, syncing data continuously, and keeping 30 days of reverse replication after the DNS switch gives you a tested rollback path.

Why European teams are reassessing Google Cloud

For many European startups and mid-sized companies, Google Cloud was an attractive starting point. Its Kubernetes engine (GKE) is mature, its networking is fast, and startup credit programs often covered the first year or two of bills.

Once the credits expire and compliance requirements mature, three factors usually trigger a reassessment:

1. Cost predictability: Google Cloud’s pricing structure separates compute, persistent disk throughput, networking, NAT gateway processing, and load balancer rules. European providers typically bundle generous bandwidth allocations and charge flat monthly rates for compute and managed services. Check each provider's current pricing page for exact figures, as structures vary between bundled and metered bandwidth.
2. Jurisdiction and sovereignty: Even when you select a Google Cloud region in Frankfurt, St. Ghislain, or Eemshaven, Google Cloud is operated by Alphabet Inc., a US corporation subject to US extraterritorial laws. So-called "sovereign" partnerships or controls on US clouds still leave ultimate corporate ownership outside Europe. Moving to an EU-owned provider ensures that both physical data centers and the legal parent entity reside under European jurisdiction.
3. Regulatory exit mandates: For companies in the financial sector—or software vendors supplying them—the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), which has applied since January 17, 2025, requires documented and tested exit strategies for ICT services supporting critical functions. Meanwhile, the EU Data Act (Regulation (EU) 2023/2854) has removed long-standing contractual and financial barriers to switching cloud providers.

Service mapping: Google Cloud to EU-owned providers

Before touching any infrastructure, map every active service on your Google Cloud invoice to its equivalent on an EU-owned cloud.

Providers like UpCloud, Scaleway, OVHcloud, IONOS, STACKIT, and Exoscale cover the standard infrastructure stack with managed services. Hetzner offers competitive raw compute, networking, and storage, though it does not offer managed databases or managed Kubernetes; if you choose Hetzner, those services must be deployed and maintained directly on virtual machines.

What moves cleanly vs. what needs engineering work

A realistic migration plan separates infrastructure plumbing from application refactoring.

Workloads that move without code changes

Virtual machines, standard Docker containers, managed PostgreSQL and MySQL databases, Redis caches, virtual private networks, firewalls, and S3-compatible object storage move with minimal friction. If your application connects to its database via a standard connection string (DATABASE_URL) and writes files using an S3 client library, your developers barely need to touch the application code.

Workloads that need assistance

Serverless functions (Cloud Functions), container-as-a-service (Cloud Run), and message queues (Pub/Sub) sit in the middle. If you use Cloud Run strictly to run stateless HTTP containers, those containers can be deployed to a managed Kubernetes cluster or a European serverless container platform like Scaleway Serverless Containers. However, if your code imports @google-cloud/pubsub or relies on Eventarc triggers when a file lands in Cloud Storage, your engineering team will need to swap the Google SDK for a standard protocol like AMQP, Kafka, or Redis Streams.

Workloads that require architectural decisions

Proprietary databases and analytics engines are the hardest part of leaving Google Cloud:

• Firestore and Datastore: Because these document databases use proprietary query APIs and client-side SDKs, leaving them requires migrating data to PostgreSQL (using jsonb columns) or an open-source document store like MongoDB, and rewriting your data access layer.
• BigQuery: Many European companies use PostgreSQL for production transactions and stream data into BigQuery for analytics. If BigQuery does not hold sensitive production state or create a regulatory blocker for your core product, you can migrate your core application infrastructure first and replace BigQuery later with ClickHouse or DuckDB.

Hidden Google Cloud dependencies to watch for

Even in standard Kubernetes or VM setups, Google-specific glue often hides in configuration files:

• Workload Identity and IAM: Applications often authenticate to Cloud Storage or Cloud SQL using Google service accounts injected at runtime rather than static credentials. On an EU cloud, you will transition to standard environment variables, Kubernetes secrets, or S3 access keys.
• Cloud SQL Auth Proxy: Many teams run the Cloud SQL Auth Proxy sidecar to handle database encryption and authentication. When moving to a European managed database, you will remove this sidecar and connect directly over private VPC networking using standard TLS certificates.
• Container Registry (Artifact Registry): Remember to update your CI/CD pipelines to push container images to an EU-hosted registry (or your existing GitHub/GitLab registry) so your new cluster does not pull images across the Atlantic during deployments.

Using the EU Data Act and Google's exit program for egress

Historically, moving terabytes of object storage and database backups out of a US hyperscaler meant paying steep network egress fees. Today, both European law and Google’s own policies protect you from punitive switching costs.

Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers could only pass on the direct technical cost of switching until January 12, 2027. From January 12, 2027 onward, all switching charges—including data egress fees incurred when moving to another provider—are banned across the European Union.

In parallel, Google Cloud operates a formal Exit Program that waives network data transfer fees for customers migrating all workloads off relevant Google Cloud services. However, you cannot simply copy your data out and expect an automatic refund. You must follow their administrative process:

1. Submit a formal "Exit Notice" form through Google Cloud support before starting the bulk transfer.
2. Wait for Google to assign a Billing Support agent (which takes up to 14 days).
3. Initiate and complete the migration within the defined window (typically starting within 30 days of approval) and terminate the covered services afterward.

If you have less than a terabyte of data, standard egress charges may be small enough that you prefer to start copying immediately. If you store tens or hundreds of terabytes in Cloud Storage, file the exit notice during your planning phase so the 14-day review runs while you build your new environment.

The 6-step migration plan

Do not treat a cloud migration as a weekend "backup and restore" marathon. Moving infrastructure safely means running both environments in parallel and cutting over only when data is already in sync.

Step 1: Analyze and inventory

Start by exporting your Google Cloud billing report and listing every active resource across all projects. Identify VM sizes, disk capacities, database versions, and average network traffic. Map these to your target EU cloud to establish a clear before-and-after monthly cost comparison. Look for forgotten resources—unattached persistent disks, old snapshots, and staging environments—that do not need to be migrated.

Step 2: Rebuild the environment as code

Do not click around in the new provider's web console. Define your target European infrastructure in Terraform or OpenTofu. Set up the Virtual Private Cloud (VPC), private subnets, firewall rules, load balancers, managed databases, and Kubernetes clusters or VMs to match your Google Cloud capacity. At this stage, no application code or production data is moved; you are simply building an empty, reproducible shell.

Step 3: Synchronize the data

With the target infrastructure running, begin continuous data replication:

• Object Storage: Enable the S3 interoperability API in Google Cloud Storage (creating HMAC keys) and use tools like rclone to copy buckets to your EU provider’s object storage. Run periodic sync passes with checksum verification so new files uploaded by users are copied over continuously.
• Relational Databases: Configure PostgreSQL or MySQL logical replication from Cloud SQL to your new managed database over an encrypted VPN or TLS connection. First, take a baseline snapshot to load existing tables, then let logical replication stream ongoing INSERT, UPDATE, and DELETE operations in real time.

Step 4: Point your deployments

Work with your engineering team to update your CI/CD pipelines (GitHub Actions, GitLab CI, etc.). Add a deployment target for the new EU environment. Deploy your stateless applications, background workers, and web servers to the new infrastructure. Connect them to the replicated database (in read-only mode initially) and verify that health checks, TLS certificates, and logging work as expected.

Step 5: Switch traffic

Once your new environment is tested and database replication lag is consistently under 5 seconds, schedule a short maintenance window during low-traffic hours.

1. Put your application on Google Cloud into maintenance or read-only mode to pause new database writes.
2. Wait a few seconds for the final transactions to replicate to the EU database, and run a final delta sync on object storage.
3. Promote the EU database to primary (read-write) and enable your background workers in the EU environment.
4. Update your DNS records (having lowered TTLs to 60 seconds a day earlier) to point to the EU load balancer.

For most standard web applications, the actual write pause takes only a few minutes.

Step 6: Keep rollback ready, then clean up

Do not delete your Google Cloud project the day after cutover. Configure reverse logical replication from your new EU primary database back to Cloud SQL, and keep the old environment on standby for 30 days. If an unexpected edge case appears, you can switch DNS back without losing data written after the cutover. Once the 30-day window passes cleanly, decommission the Google Cloud resources and close the billing account.

Practical pre-migration checklist

Use this checklist before scheduling your cutover window:

• Billing & Egress: Submit Google Cloud’s Exit Notice form if transferring large data volumes, and verify committed use discount (CUD) expiration dates.
• Auth & Secrets: Replace Google Workload Identity and Secret Manager calls with standard environment variables, Kubernetes Secrets, or HashiCorp Vault.
• Storage APIs: Verify whether application code uses the native @google-cloud/storage SDK or an S3-compatible client; refactor to S3 SDKs where necessary.
• Database Extensions: Check that all PostgreSQL extensions enabled in Cloud SQL (such as pgvector, postgis, or pg_stat_statements) are supported by your target EU provider's managed database.
• Email & Outbound IPs: Update SPF records, webhook allowlists, and third-party API IP filters with the new outbound NAT IP addresses of your EU cloud.
• DNS Preparation: Lower DNS TTLs to 60–300 seconds at least 48 hours before the planned switch.

Frequently asked questions

Can we keep BigQuery or Google Workspace while moving our core infrastructure?

Yes. Google Workspace (Gmail, Drive, Docs) is completely separate from Google Cloud infrastructure and does not need to change. You can also keep BigQuery for historical data analytics if your team relies on it, while moving your production VMs, Kubernetes clusters, and transactional PostgreSQL databases to an EU provider. Just keep in mind that streaming data from an EU cloud into BigQuery will still subject that analytics data to US jurisdiction.

How much downtime is required to move a Cloud SQL database?

While migrations with no downtime at all do not exist when changing database primaries across clouds, logical replication keeps the required maintenance window very short. Because historical data is synced in advance while the app stays live, you only need to pause writes long enough for the last few seconds of replication lag to drain and for connections to switch to the new database—typically between 2 and 10 minutes.

Do we have to rewrite our Terraform files from scratch?

Yes, the resource blocks must change because Terraform providers are cloud-specific (google_compute_instance becomes upcloud_server or scaleway_instance_server). However, your overall module structure, network topology, variable definitions, and state management concepts carry over directly.

What happens if we have active Committed Use Discounts (CUDs) on Google Cloud?

Google Cloud’s free data transfer program waives network egress fees, but it does not automatically cancel fixed-term financial commitments like 1-year or 3-year CUDs. Review your billing console to see when your commitments expire. In many cases, the monthly savings on an EU provider offset the remaining commitment within a few months, or you can time your cutover to align with the CUD renewal date.

How MoveInfra can help

MoveInfra moves companies from Google Cloud to EU-owned providers like UpCloud, Scaleway, Hetzner, and OVHcloud for a fixed price. You can upload your Google Cloud bill for a free analysis and monthly cost comparison, after which we rebuild your infrastructure in Terraform, sync your databases and storage with checksums, and handle the cutover with 30 days of reverse replication for rollback. If you want to move off Google Cloud without derailing your engineering roadmap, request early access at moveinfra.eu.

Sources

• Regulation (EU) 2023/2854 (EU Data Act) on EUR-Lex
• Regulation (EU) 2022/2554 (Digital Operational Resilience Act - DORA) on EUR-Lex
• Google Cloud Documentation: Data Portability and Switching Procedures
• UpCloud Documentation
• Scaleway Documentation

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

Moving from AWS to OVHcloud is a practical route for European companies that want to bring their cloud infrastructure under EU jurisdiction while keeping managed services like Kubernetes, relational databases, and S3-compatible object storage. A successful migration requires mapping your AWS resources to OVHcloud Public Cloud equivalents, rebuilding your network and compute layer using Infrastructure as Code, syncing data continuously via logical replication, and switching DNS traffic during a brief, planned write pause. Most standard web applications, container clusters, and relational databases map directly between the two platforms, though proprietary AWS services like DynamoDB or SQS must be replaced with open-source alternatives during the transition.

Key takeaways

• Direct service mapping for core workloads: OVHcloud Public Cloud provides direct equivalents for EC2, RDS (PostgreSQL and MySQL), S3, EKS, and ElastiCache (via managed Valkey/Redis).
• Open standards under the hood: OVHcloud builds its Public Cloud on OpenStack and CNCF-certified vanilla Kubernetes, which makes it straightforward to manage via Terraform and standard APIs.
• More predictable bandwidth costs: Unlike AWS, which charges per gigabyte for internet egress, OVHcloud includes incoming and outgoing public network traffic in the base price of its Public Cloud instances and Managed Kubernetes worker nodes.
• Switching fees are regulated: Under Article 29 of the EU Data Act, AWS can charge no more than its direct cost for data egress when you switch providers until 12 January 2027, after which switching fees are banned entirely.
• Proprietary services require refactoring: If your architecture relies heavily on AWS Lambda, DynamoDB, or CloudFormation, you will need to adapt those components to open standards before or during the move.

Why European companies move from AWS to OVHcloud

For companies with 10 to 300 employees, the decision to leave AWS for a European provider usually comes down to two factors: legal jurisdiction and cost predictability.

Jurisdiction and compliance

AWS operates several data center regions inside the European Union, as well as the AWS European Sovereign Cloud. While these options keep data and day-to-day operations inside the EU, Amazon remains a US parent company subject to extraterritorial US laws, such as the CLOUD Act.

OVHcloud is headquartered in Roubaix, France, and is subject to European and French law. For companies in regulated industries, or those dealing with public-sector procurement and strict enterprise vendor assessments, hosting on an EU-owned cloud simplifies compliance. Furthermore, for financial entities subject to the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), which has applied since 17 January 2025, having a tested exit strategy away from dominant ICT providers is a regulatory requirement.

Cost structure and egress

AWS pricing is highly granular. While base compute and storage prices are clear, monthly bills often grow unpredictable due to charges for NAT Gateways, cross-Availability Zone (AZ) data transfer, and public internet egress.

OVHcloud structures its pricing around bundled resources. On OVHcloud Public Cloud, standard public bandwidth (both ingress and egress) and private network traffic over vRack are included in the monthly or hourly price of compute instances. Similarly, the OVHcloud Managed Kubernetes Service (MKS) Free plan provides the cluster control plane at no charge, meaning you only pay for the underlying worker node instances, block storage, and load balancers. (OVHcloud also offers a paid MKS Standard plan with higher SLA guarantees and 3-AZ deployment options; check the official OVHcloud pricing page for current 2026 rates.)

Mapping AWS services to OVHcloud equivalents

Before moving any workloads, you need an accurate inventory of what you run on AWS and how each component translates to OVHcloud. Most infrastructure falls into OVHcloud’s "Public Cloud" product line, rather than their traditional bare-metal dedicated servers or VPS offerings.

Architectural differences to plan for

While the service table shows strong parity for standard stacks, the underlying mechanics of AWS and OVHcloud differ in several ways that affect your engineering team.

1. Region topology (1-AZ vs. 3-AZ)

In AWS, every region consists of at least three Availability Zones by default, and architectures are built around multi-AZ subnets from day one. OVHcloud historically built its Public Cloud regions (such as Gravelines GRA and Strasbourg SBG in France, or Limburg LIM in Germany) as single-datacenter locations, oftenwith multiple independent rooms on the same campus.

However, OVHcloud has expanded its multi-availability-zone footprint, offering 3-AZ region deployments (starting with the Paris region) for Public Cloud and Managed Kubernetes Standard. When planning your move, check which specific services and database engines are available in your chosen OVHcloud region, and decide whether your availability requirements call for a 3-AZ region or multi-region replication.

2. IAM and API credentials

AWS relies on a single, unified IAM system across every service, allowing fine-grained role assumption (such as IAM Roles for Service Accounts in EKS).

OVHcloud uses a two-layer API structure for its Public Cloud:

1. The OVHcloud API: Used for account management, billing, vRack creation, Managed Kubernetes cluster provisioning, and Managed Databases.
2. The OpenStack API: Because OVHcloud Public Cloud runs on OpenStack, low-level resources like compute instances, security groups, block storage volumes, and S3 object storage credentials can be managed directly through standard OpenStack APIs.

In Terraform, it is common practice to configure both the ovh provider and the openstack provider side by side. This also means your applications cannot rely on AWS-specific IAM instance profiles; instead, you will pass standard S3 access keys or database connection strings via environment variables or Kubernetes secrets.

3. Networking and vRack

In AWS, a VPC is a software-defined network isolated to a single region. In OVHcloud, private networking is built on vRack (Virtual Rack). vRack allows you to create isolated Layer 2/Layer 3 private networks that can span across multiple OVHcloud data centers and even bridge Public Cloud virtual instances with dedicated bare-metal servers.

When translating an AWS VPC to OVHcloud, you will attach a vRack to your Public Cloud project, define private networks (subnets) with DHCP enabled, and deploy an OpenStack Gateway instance (which acts similarly to a combined AWS Internet Gateway and NAT Gateway) so private worker nodes can reach the outside internet.

Step-by-step migration plan

To avoid extended downtime or data loss, treat the migration as a parallel build followed by a controlled cutover, rather than a manual "backup and restore" weekend project.

Step 1: Audit your bill and inventory resources

Start by pulling your last three months of AWS bills and inspecting your live environment. List every active EC2 instance, RDS cluster, S3 bucket, load balancer, and DNS zone.

Pay special attention to hidden dependencies:

• Are your applications using AWS SES for transactional email? (You can keep SES while hosting compute on OVHcloud, or switch to an EU email provider.)
• Are you using AWS KMS or Secrets Manager?
• Are images stored in Amazon ECR?

Step 2: Rebuild the infrastructure as code

Do not click through the OVHcloud Control Panel to build production environments. Translate your existing Terraform, OpenTofu, or CloudFormation templates into Terraform modules using the ovh and openstack providers.

Provision the foundational layer first:

• vRack, private subnets, and routing gateways.
• Security groups mirroring your AWS ingress/egress rules.
• Managed Kubernetes clusters or compute instances matching your current vCPU and RAM sizing.
• Empty Managed PostgreSQL/MySQL databases and S3-compatible Object Storage buckets.

Step 3: Set up continuous data synchronization

Moving gigabytes or terabytes of data takes time. Instead of stopping your application to take a snapshot, synchronize data while the AWS environment remains live:

• Object Storage: Use a tool like rclone to copy objects from AWS S3 to OVHcloud Object Storage. Run an initial bulk sync, followed by periodic incremental syncs with checksum verification enabled.
• Relational Databases: Configure logical replication between AWS RDS and OVHcloud Public Cloud Databases. For PostgreSQL, use native CREATE PUBLICATION and CREATE SUBSCRIPTION after loading an initial schema and base backup. For MySQL, configure binlog replication from the AWS source to the OVHcloud replica.

Keep this replication running until replication lag drops to near zero.

Step 4: Point your CI/CD pipelines

Update your GitHub Actions, GitLab CI, or ArgoCD pipelines to deploy your application code to the new OVHcloud environment alongside AWS. Verify that container images pull cleanly, environment variables and secrets are mounted properly, and internal services can communicate over the vRack private network. Run end-to-end tests against the OVHcloud staging URL or load balancer IP before routing real user traffic.

Step 5: Execute the cutover and keep a rollback path

Twenty-four hours before your planned switch, lower the TTL (Time to Live) on your DNS records (in Route 53, Cloudflare, or your DNS provider) to 60 seconds.

At the scheduled cutover window:

1. Put your application into maintenance mode or pause database writes on the AWS side.
2. Wait until database replication lag reaches zero (typically under 5 seconds once writes stop) and run a final rclone pass on object storage.
3. Promote the OVHcloud database to primary (standalone writable).
4. Update your DNS records to point to the OVHcloud Load Balancer IPs.
5. Re-enable writes on the OVHcloud environment.

For critical workloads, configure reverse logical replication from OVHcloud back to AWS for the first two to four weeks. Leaving the old AWS environment running (or scaled down with synced data) gives you a reliable rollback option before you permanently delete your AWS resources.

Planning checklist: AWS to OVHcloud

Use this checklist with your engineering and operations team before scheduling a cutover date:

• EU Data Act fee waiver requested: If you are transferring significant data volume out of AWS, submit an exit switching request under the AWS EU Data Act Addendum in advance to have switching egress fees reduced or waived.
• Region and AZ requirements verified: Confirm whether a standard OVHcloud region (GRA, SBG, LIM, BHS) or a 3-AZ region (PAR) matches your resilience needs and supports all required managed services.
• Quota limits raised: New OVHcloud Public Cloud projects have default OpenStack quotas for vCPUs, RAM, and instances. Request quota increases via OVHcloud support before running your Terraform apply.
• S3 SDK compatibility tested: Ensure your application's S3 client libraries support custom endpoint URLs and path-style or virtual-hosted-style addressing as used by OVHcloud Object Storage.
• Database extensions checked: Compare installed PostgreSQL extensions or MySQL plugins on AWS RDS against the supported extensions list in OVHcloud Public Cloud Databases.
• SSL/TLS certificates provisioned: If you use AWS Certificate Manager (ACM) attached to an ALB, plan to replace it with Let's Encrypt (cert-manager on Kubernetes) or imported certificates on the OVHcloud Load Balancer, as ACM certificates cannot be exported.

Frequently asked questions

Can I keep using S3 tools and SDKs with OVHcloud Object Storage?

Yes. OVHcloud Object Storage supports the standard S3 API. You can continue using the official AWS SDKs (such as boto3 for Python or @aws-sdk/client-s3 for Node.js), the AWS CLI, and backup tools like restic or velero. You only need to change the endpoint URL, region identifier, and access credentials in your application configuration.

Does AWS charge egress fees when I migrate to OVHcloud?

Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers may charge no more than direct costs for switching-related data egress until 12 January 2027, and must remove switching charges completely from 12 January 2027 onward. AWS provides a formal process under its EU Data Act Addendum to request reduced or waived data transfer fees when switching to another provider. Note that you must apply to AWS Support prior to migrating the data, and standard fees still apply if you keep running a permanent multi-cloud setup rather than completing a switch.

What happens to my AWS ACM SSL certificates during the move?

Public SSL/TLS certificates generated through AWS Certificate Manager (ACM) are bound to AWS services like Elastic Load Balancing and CloudFront and cannot be exported. When moving to OVHcloud, you will need to issue new certificates—typically by automating Let's Encrypt via cert-manager on Kubernetes or ACME clients on your load balancers—prior to switching your DNS records.

How long does a typical AWS to OVHcloud migration take?

For a small to mid-sized company running standard virtual machines, a managed Kubernetes cluster, PostgreSQL/MySQL, and S3 storage, the end-to-end process typically takes two to four weeks of calendar time. Most of that time is spent writing and testing the Terraform code, verifying CI/CD deployments, and letting initial database and storage replication complete in the background. The actual cutover window usually requires only a few minutes of paused writes.

How MoveInfra can help

MoveInfra automates the infrastructure transition from AWS to EU-owned clouds, including OVHcloud. You start by uploading your cloud bill for a free inventory and fixed-price quote, after which MoveInfra rebuilds your environment on OVHcloud as clean Terraform code, syncs your databases and object storage with live replication, and helps your team point your CI/CD pipelines to the new setup. Once replication lag is under five seconds, we coordinate the DNS switch during a brief write pause and maintain 30 days of reverse replication so you always have a safe rollback option.

Sources

• Regulation (EU) 2023/2854 (EU Data Act) on EUR-Lex
• Regulation (EU) 2022/2554 (DORA) on EUR-Lex
• OVHcloud Public Cloud Documentation
• OVHcloud Public Cloud Pricing
• AWS Data Transfer Pricing and Switching FAQs

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

Migrating from AWS to Scaleway means moving from a sprawling catalog of over 200 proprietary services to a focused, European-owned cloud built on open standards. For most small and mid-sized engineering teams, Scaleway covers the core infrastructure stack directly: virtual machines, managed Kubernetes, managed PostgreSQL and MySQL, Redis-compatible caching, S3-compatible object storage, and even SQS/SNS-compatible messaging. The transition is straightforward for standard web applications and containerized workloads, while architectures heavily tied to AWS-specific services like DynamoDB or Redshift require either refactoring or a phased migration.

Key takeaways

• Direct mappings for core workloads: Compute (EC2 to Instances), containers (EKS to Kapsule), relational databases (RDS to Managed Databases), and storage (S3 to Object Storage) have direct equivalents on Scaleway.
• Built-in protocol compatibility: Scaleway supports the S3 API for storage and implements the AWS SQS and SNS protocols for queuing and messaging, reducing the need to rewrite application code.
• European jurisdiction: Scaleway is a French company (part of the Iliad Group) operating data centers in Paris, Amsterdam, Warsaw, and Milan under EU law.
• Predictable cost structure: Scaleway uses flat, resource-based pricing with free private network traffic, removing the complex per-gigabyte internal routing charges common on AWS.
• Clear boundaries on proprietary tools: AWS-specific services like DynamoDB, Cognito, and Redshift do not have drop-in managed equivalents on Scaleway and require open-source alternatives.

Why European teams move from AWS to Scaleway

For companies of 10 to 300 people, AWS often provides more complexity than the business actually uses. Teams end up paying a premium—both in monthly bills and engineering time—to configure VPC peering, NAT gateways, IAM policy chains, and granular billing alarms.

Scaleway offers a middle ground between bare-bones server hosts and US hyperscalers. Founded in 1999 and headquartered in Paris as a subsidiary of the Iliad Group, Scaleway operates Multi-AZ regions in the European Union, including Paris (fr-par), Amsterdam (nl-ams), and Warsaw (pl-waw). Because it is EU-owned and operated, customer data stays within European jurisdiction without exposure to the US CLOUD Act. In contrast, even the AWS European Sovereign Cloud remains owned by Amazon, a US corporation.

Regulatory requirements also drive the move. The Digital Operational Resilience Act (DORA), which applies from January 17, 2025, requires financial entities and their critical ICT providers to maintain practical exit strategies and avoid concentration risk. Furthermore, under Article 29 of the EU Data Act, cloud switching charges—including data egress fees when moving to another provider—are capped at cost until January 12, 2027, and banned entirely from that date onward.

Service-by-service comparison: AWS to Scaleway

Before moving any workload, you need an accurate map of how your current AWS resources translate to Scaleway products.

Deep dive into key infrastructure areas

Compute and containers

If you run virtual machines on EC2, Scaleway splits its Instances into Development (shared resources for staging and testing) and Production ranges (General Purpose POP2, Compute Optimized COP, and Memory Optimized MOP with dedicated vCPUs). Like AWS, Scaleway separates compute from network-attached Block Storage, allowing you to resize volumes independently.

For teams on Amazon EKS, Scaleway's Kubernetes Kapsule is often the easiest part of the migration. EKS relies heavily on AWS-specific IAM roles for service accounts (IRSA), custom VPC CNI plugins, and ALB Ingress Controllers. Kapsule runs certified, upstream Kubernetes with a free managed control plane. When migrating, you replace AWS-specific annotations on your Ingress and StorageClass manifests with Scaleway's CSI (Container Storage Interface) and Load Balancer annotations, then apply the same deployments.

Relational databases and caching

Scaleway offers Managed Databases for PostgreSQL and MySQL with standalone or High Availability (HA) configurations. An HA cluster provisions a standby node in a separate Availability Zone with synchronous replication.

Moving from RDS or Aurora PostgreSQL/MySQL does not require changing your database schema, provided you are not using proprietary Aurora extensions. The safest migration method is logical replication. You provision the target database on Scaleway, take an initial snapshot of your AWS database, and stream ongoing changes (Write-Ahead Logs in PostgreSQL or binlogs in MySQL) over an encrypted connection until the Scaleway database is in sync.

For caching, AWS ElastiCache maps to Scaleway's Managed Database for Redis. Because cache data is normally transient, most teams simply deploy a new Redis cluster in Scaleway's Private Network and let the application populate the cache after cutover.

Object storage and CDN

Scaleway Object Storage is built on the S3 API. If your application uses boto3, the AWS SDK for JavaScript, or any standard S3 client, you do not need to rewrite your storage logic. You only change the region (for example, fr-par) and the endpoint URL (https://s3.fr-par.scw.cloud) in your client configuration.

Scaleway also includes Multi-AZ redundancy as standard in its main regions and provides archival tiers (Scaleway Glacier) that respond to standard S3 restore commands. For content delivery, Scaleway Edge Services provides caching and custom TLS domains in front of buckets, replacing basic Amazon CloudFront setups.

Networking and security

Networking is where engineers notice the biggest philosophical difference between AWS and Scaleway. On AWS, designing a VPC requires calculating CIDR blocks for public and private subnets across each Availability Zone, configuring route tables, and paying hourly and per-gigabyte fees for NAT Gateways so private instances can reach the internet.

Scaleway simplifies this with VPC and Private Networks. A Private Network is a regional Layer 2/Layer 3 network that spans all Availability Zones in a region. You attach Instances, Kubernetes clusters, Managed Databases, and Load Balancers directly to the Private Network. For outbound internet access from private resources, Scaleway offers a Public Gateway (managed NAT), which is billed at a flat hourly/monthly rate without per-gigabyte processing charges.

Queues, serverless, and application services

Many European cloud providers lack application-level middleware, forcing teams to self-host RabbitMQ or Kafka when leaving AWS. Scaleway is an exception here. Its Queues and Topics and Events services are built as compatible implementations of the AWS SQS and AWS SNS protocols (alongside native support for CNCF NATS). In many cases, you can keep using the AWS SDK in your worker services by pointing the endpoint to Scaleway's messaging API, though you should check Scaleway's documentation for specific SQS parameters your app might rely on.

For serverless workloads, Scaleway provides Serverless Functions (supporting Python, Node.js, Go, PHP, and Rust) and Serverless Containers (comparable to AWS App Runner or Fargate). While the concepts are identical, event payloads and IAM bindings differ from AWS Lambda, so you will need to adapt your function entrypoints and Terraform definitions.

What does not map directly

Being realistic about what Scaleway cannot do is the most important part of migration planning. You will need to rethink your architecture if you rely on:

• Proprietary NoSQL (DynamoDB): Scaleway does not have a managed key-value/document store equivalent to DynamoDB. Teams migrating off DynamoDB typically move the data into PostgreSQL using JSONB columns, or use a managed MongoDB/Cassandra service hosted on EU regions via a third-party provider.
• Cloud Data Warehouses (Redshift): Scaleway does not offer a managed petabyte-scale data warehouse. Teams usually migrate analytical workloads to self-hosted ClickHouse on Scaleway Instances/Kubernetes, or use PostgreSQL with analytical extensions for smaller datasets.
• Complex IAM and Cognito: Scaleway IAM supports users, groups, applications, and policy rules scoped to projects and resource types, which is sufficient for infrastructure access control. However, if you use Amazon Cognito for end-user authentication, you will need to migrate to an open-source identity provider like Keycloak or an EU-hosted auth service.

Practical migration checklist

If you are planning a move from AWS to Scaleway, follow this sequence to keep risk low and rollback options open:

1. Audit your AWS bill and Terraform state: List every active service across all AWS regions. Flag any proprietary services (DynamoDB, Lambda, SQS, Cognito) that need specific compatibility checks.
2. Choose your target Scaleway region: Select Paris (fr-par), Amsterdam (nl-ams), or Warsaw (pl-waw) based on user latency and data residency needs. Verify that all required instance types exist in your chosen Availability Zones.
3. Rebuild infrastructure as code: Write new Terraform or OpenTofu configurations using the official scaleway/scaleway provider. Set up your VPC, Private Networks, Security Groups, and Public Gateways first.
4. Provision and sync stateful stores: Launch Managed PostgreSQL/MySQL and Object Storage buckets. Start continuous logical replication from RDS to Scaleway, and use rclone or a similar checksum-verified tool to sync S3 buckets.
5. Adapt CI/CD pipelines: Update your GitHub Actions or GitLab CI workflows to push container images to Scaleway Container Registry and deploy to your new Scaleway Instances or Kapsule cluster alongside AWS.
6. Test in parallel: Run synthetic traffic and integration tests against the Scaleway environment using staging domains before touching production DNS.
7. Execute the DNS cutover: Lower DNS TTLs ahead of time. During a scheduled maintenance window, pause writes on the AWS application, verify that database replication lag is near zero, promote the Scaleway database to primary, and update your DNS records.
8. Maintain a rollback window: Keep the AWS environment alive (and ideally syncing data back from Scaleway) for two to four weeks before deleting AWS resources and closing the account.

Frequently asked questions

Can I keep using the AWS SDK for S3 and SQS on Scaleway?

Yes. Scaleway Object Storage is compatible with the Amazon S3 API, and Scaleway Queues and Topics/Events implement the AWS SQS and SNS protocols. In most languages, you can continue using the official AWS SDK by overriding the endpoint_url and region parameters and supplying your Scaleway access and secret keys. Always test specific features like S3 lifecycle rules or SQS dead-letter queues in staging first.

How does Scaleway pricing compare to AWS?

Scaleway generally offers lower and more predictable pricing than AWS, particularly on bandwidth and Kubernetes management. The Kubernetes Kapsule control plane is free (you only pay for worker nodes), and egress traffic is significantly cheaper than standard AWS data transfer rates. Because prices vary by instance family and region, check the official Scaleway pricing page for current 2026 list prices.

Does Scaleway support Terraform and OpenTofu?

Yes. Scaleway maintains an official, well-documented provider in the Terraform and OpenTofu registries. You can manage almost all resources—including Instances, Kapsule clusters, Managed Databases, Object Storage buckets, and IAM policies—entirely through code.

How much downtime is required to switch from AWS to Scaleway?

For standard web applications using PostgreSQL, MySQL, and S3, the infrastructure is built and synced while AWS remains live. The actual switch only requires a brief planned write pause—typically a few minutes—to let the final database transactions replicate, run sanity checks, and flip the DNS records.

How MoveInfra can help

If your team wants to move from AWS to Scaleway without spending weeks writing new Terraform modules and managing live database replication by hand, MoveInfra can run the transition for you. Upload your AWS bill for a free analysis and fixed migration price, and we will rebuild your infrastructure as code on Scaleway, sync your databases and S3 buckets in the background, and help your team point your CI/CD pipelines to the new environment. When replication lag is under five seconds, we coordinate a short planned cutover and keep reverse replication running for 30 days so you always have a safe rollback option.

Sources

• Scaleway Product Documentation
• Scaleway Queues Overview (SQS Compatibility)
• Scaleway Pricing Overview
• Regulation (EU) 2023/2854 (EU Data Act) on EUR-Lex
• Regulation (EU) 2022/2554 (DORA) on EUR-Lex

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

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.

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:

1. Put your application into a brief read-only or maintenance mode (pausing new database writes).
2. Verify that replication lag has reached zero—meaning every last transaction from the old cloud is now present in the European database.
3. Run a final delta sync on object storage buckets.
4. Promote the European database to be the primary standalone database.
5. Enable writes on the new European application environment.
6. 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.

Sources

• Regulation (EU) 2023/2854 (EU Data Act) on EUR-Lex
• Regulation (EU) 2022/2554 (Digital Operational Resilience Act - DORA) on EUR-Lex
• PostgreSQL Official Documentation: Logical Replication
• UpCloud Official Documentation and Pricing
• Scaleway Official Documentation
• Hetzner Official Documentation

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

On 12 January 2027, Article 29 of the EU Data Act (Regulation (EU) 2023/2854) takes full effect, making it illegal for cloud providers to charge switching fees—including data egress fees—when an EU customer moves to another provider or to on-premises infrastructure. Since 12 September 2025, providers have only been allowed to charge at-cost rates for switching and have been bound by strict contract rules, such as a maximum two-month notice period and a 30-day transition window. While the January 2027 deadline eliminates the financial penalty for exporting your data during a migration, it does not ban standard ongoing egress fees for everyday traffic, abolish fixed-term contract commitments, or solve the technical work of rebuilding your infrastructure on a new cloud.

Key takeaways

• Zero switching fees from 12 January 2027: Cloud providers can no longer charge data egress fees or administrative penalties when you export your data and metadata to switch providers.
• Contract rules already apply: Since 12 September 2025, Chapter VI of the EU Data Act has capped customer notice periods at two months and required a mandatory 30-day transition period.
• Everyday egress is still billed: The fee ban applies only to switching and parallel multi-cloud use (which remains capped at provider cost). Standard internet traffic and cross-region transfers in normal operations remain billable.
• Commitments still hold: Fixed-term contracts, reserved instances, and savings plans are not invalidated by the law. Early termination penalties remain legal if they are proportionate.
• Financial lock-in ends, technical work remains: Removing egress bills makes leaving a hyperscaler cheaper, but engineering teams still have to translate networks, IAM policies, and deployment pipelines.

What the EU Data Act actually does for cloud customers

Regulation (EU) 2023/2854, known as the EU Data Act, entered into force in January 2024 and became generally applicable across the European Union on 12 September 2025. While much of the law deals with connected IoT devices and industrial data sharing, Chapter VI (Articles 23 to 31) targets a major operational headache for European software companies: cloud vendor lock-in.

In the text of the regulation, cloud platforms are called "data processing services". This definition covers Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). Importantly, the law applies based on where the customer is located, not where the provider has its headquarters. Whether you buy cloud infrastructure from AWS, Microsoft Azure, Google Cloud, DigitalOcean, or a European provider, Chapter VI applies to your contracts if your company is established in the EU.

The law breaks vendor lock-in down into three categories: contractual barriers, commercial barriers (fees), and technical barriers. Most of the contractual and technical rules took effect in September 2025. The commercial phase-out finishes on 12 January 2027.

The timeline: 2024 to 2027

The rollout of the cloud switching rules follows a three-stage schedule under Articles 29 and 50 of the regulation:

1. 11 January 2024 – 12 January 2027 (Transitional period for fees): Under Article 29(2), providers were immediately barred from increasing switching charges and could only pass on the direct, actual costs incurred to execute a customer switch.
2. 12 September 2025 (General application): All contractual obligations under Article 25 and technical assistance obligations under Articles 26 through 30 took effect. Providers had to update their terms of service to allow switching upon request.
3. 12 January 2027 (Complete ban on switching charges): Under Article 29(1), switching charges drop to zero. Providers cannot charge for data egress, specialized export tooling, or support actions required to complete a migration to a new provider.

What changes on 12 January 2027 (and what does not)

Many summaries of the EU Data Act claim that "cloud egress fees are banned in 2027". That is inaccurate and can lead to expensive mistakes in architecture planning. The regulation draws a sharp line between switching (leaving a service), in-parallel use (running a multi-cloud setup across providers), and ongoing operations (serving your application to users).

1. Switching to another provider: Free from January 2027

When you formally initiate a switch to move a workload from one cloud provider to another—or back to your own hardware—Article 29(1) prohibits the source provider from charging switching fees. This includes outbound data transfer (egress) fees for moving your databases, object storage buckets, virtual machine images, and configuration metadata to the destination provider.

2. Multi-cloud and parallel use: Capped at cost permanently

What if you are not leaving AWS or Google Cloud entirely, but want to run a database on one cloud and your Kubernetes cluster on an EU cloud? The Data Act calls this "in-parallel use". Under Article 34(2), providers are allowed to charge data egress fees for ongoing traffic between two clouds used in parallel, even after 12 January 2027. However, those fees cannot exceed the provider's actual technical cost of transferring the data. They cannot add a commercial markup to punish multi-cloud architectures.

3. Normal operational egress: Still billed at standard rates

The Data Act does not regulate what a cloud provider charges you to serve web traffic, software downloads, or video streams to your end users over the public internet. It also does not cap internal transfer charges, such as traffic crossing Availability Zones (AZs), NAT gateway processing fees, or inter-region replication within the same provider.

Your contractual rights under Article 25

While the removal of egress fees gets the most attention, the contractual timeline rules in Article 25 are just as important when planning an infrastructure migration. Every cloud contract with an EU customer must include these baseline terms:

• Maximum 2-month notice period: You have the right to initiate a switch at any time by giving notice. The provider cannot require a notice period longer than two months.
• Mandatory 30-day transition period: Once the notice period ends, the provider must assist with the migration and complete the transition within a maximum of 30 calendar days. If the provider can prove that a 30-day transition is technically impossible, they must notify you within 14 working days and may extend the transition period once, up to seven months. As a customer, however, you always have the right to extend the transition period to a timeframe that fits your engineering schedule.
• Continuity and security: During the transition, the source provider must maintain business continuity, provide reasonable assistance, and keep a high level of security for your data and services.
• Minimum 30-day data retrieval window: After the transition period concludes, you have at least 30 calendar days to retrieve any remaining exportable data before the provider deletes it.
• Automatic termination: Your old contract terminates automatically once the switching process is successfully completed, or at the end of the two-month notice period if you decide not to migrate your data and simply want to close the account.

How hyperscaler exit programs work in practice

In response to the regulation, AWS, Google Cloud, and Microsoft Azure introduced formal data transfer waivers for customers leaving their platforms. However, as of 2026, these waivers are rarely automatic at the billing level.

Instead of simply making outbound transfers free when you delete an S3 bucket or a Cloud Storage bucket, hyperscalers generally require you to open a support case before you begin the migration, declare your intent to switch under the EU Data Act terms, and specify the accounts and timeline involved. You then pay the standard egress invoice and receive a credit refund afterward, or operate under a time-limited fee waiver tied to account closure. If you copy 50 terabytes of object storage to a new provider before submitting the formal switching notice, you risk paying standard list prices for that transfer.

The catch with Reserved Instances and Enterprise Agreements

The EU Data Act gives you the right to exit a cloud contract with two months' notice, even if you signed a three-year enterprise commitment. However, Recital 89 and Article 2(36) explicitly state that proportionate early termination penalties are not considered switching charges.

If you signed a three-year spend commitment or bought three-year Reserved Instances in exchange for a 40% discount, the provider can still bill you an early termination fee to recoup the unearned discount or require you to pay out the remaining committed balance, depending on your contract terms. Furthermore, you must continue paying standard service fees for the compute and storage you consume while the migration is underway.

Differentiating the EU Data Act, DORA, and data sovereignty

For European founders, CFOs, and CTOs, the EU Data Act sits alongside two other major considerations: financial sector compliance (DORA) and foreign legal jurisdiction.

DORA and cloud exit strategies

If your company is a financial entity—or a critical ICT third-party provider selling to banks, insurers, or payment processors—the Digital Operational Resilience Act (Regulation (EU) 2022/2554, or DORA) has applied to you since 17 January 2025. DORA requires documented, tested exit strategies for ICT services supporting critical or important functions.

Previously, DORA created a frustrating mismatch: financial regulators required you to have a credible cloud exit plan, while cloud contracts and egress fees made executing that plan slow and expensive. The EU Data Act fixes the supplier side of this equation. By mandating a 30-day transition window, documented export formats, and zero switching charges from January 2027, the Data Act gives regulated companies the legal enforcement mechanism to make their DORA exit plans work in reality.

Switching vs. sovereignty

It is also helpful to separate data portability from legal sovereignty. In response to European regulatory pressure, US hyperscalers have launched specialized regions, such as the AWS European Sovereign Cloud. While the AWS European Sovereign Cloud keeps data and operations physically inside the EU and is run by EU-resident personnel, it still belongs to Amazon, a US parent company. As a result, it remains subject to US jurisdiction and extraterritorial laws like the US CLOUD Act.

The EU Data Act does not force you to leave US providers, nor does it solve US CLOUD Act exposure on its own. What it does is remove the financial penalty if you decide that moving to an EU-owned cloud—such as UpCloud, Scaleway, Hetzner, OVHcloud, STACKIT, IONOS, or Exoscale—is the right step for your company's compliance posture and infrastructure budget.

Checklist: preparing for a cloud switch in 2027

Because the commercial barriers drop to zero on 12 January 2027, late 2026 and early 2027 are practical windows to review your cloud infrastructure. However, the Data Act only requires providers to give you "functional equivalence" for basic IaaS (like virtual machines and block storage). For PaaS and managed services, providers only have to export your raw data and specify open interfaces—they do not have to rebuild your architecture on the new cloud.

Use this checklist before triggering a formal switch:

• Audit commitment end dates: Check your billing console for active Reserved Instances, Savings Plans, Committed Use Discounts (CUDs), or multi-year enterprise discount agreements. Align your migration window with their expiration to avoid early termination fees.
• Separate portable services from proprietary lock-in: Identify which workloads run on open standards (Linux VMs, Docker/Kubernetes, PostgreSQL, MySQL, Redis, S3-compatible object storage) and which rely on proprietary services (such as AWS DynamoDB, Google BigQuery, or Azure Cosmos DB) that require application code changes before moving.
• Measure your total data volume: Calculate the exact size of your databases, persistent disks, and object storage buckets. Check how long a full initial sync and checksum verification will take over your available network bandwidth so you know if the standard 30-day transition window is sufficient.
• Read your provider's Data Act switching addendum: Locate the specific support ticket workflow your current provider requires to waive egress fees under Article 29. Do not start transferring large datasets before receiving written confirmation that your switching window is active.
• Plan for parallel run and rollback: Budget for running your old and new environments side-by-side during the cutover, and keep reverse replication active for at least a few weeks after switching DNS so you have a safe rollback option.

Frequently asked questions

Are all cloud egress fees banned in the EU starting 12 January 2027?

No. Only egress fees and administrative charges incurred as part of switching to another provider (or moving to on-premises infrastructure) are banned under Article 29(1). Standard outbound internet traffic to your end users, cross-AZ traffic, and inter-region transfers remain billable at your provider's normal rates. Egress for ongoing multi-cloud (in-parallel) use remains billable, though capped at the provider's actual technical cost.

Does the EU Data Act apply to existing contracts signed before September 2025?

Yes. The switching rules in Chapter VI of the EU Data Act apply to all contracts for data processing services provided to EU customers, regardless of when the contract was originally signed.

Can I cancel a 3-year AWS or Azure commitment early without paying a penalty?

You have the legal right under Article 25 to terminate the contract with a maximum of two months' notice to switch providers. However, the provider is still legally allowed to charge a proportionate early termination penalty to recover discounts granted for the fixed-term commitment.

Does the EU Data Act apply in the UK, Norway, or Switzerland?

The EU Data Act applies directly across the 27 EU Member States. For EEA countries (Norway, Iceland, and Liechtenstein), it takes effect once formally incorporated into the EEA Agreement. It does not apply in the United Kingdom or Switzerland, though UK regulators have conducted their own investigations into cloud switching barriers and many providers apply similar switching workflows across their European customer base.

How MoveInfra can help

While the EU Data Act removes the egress fee penalty for leaving a hyperscaler, your team still has to rebuild the infrastructure, sync the data, and cut over without losing writes. MoveInfra moves companies from AWS, Google Cloud, Azure, and DigitalOcean to EU-owned clouds like UpCloud, Scaleway, Hetzner, and OVHcloud for a fixed price. We rebuild your environment as clean Terraform code, keep your databases and object storage in live sync during the transition, help update your CI/CD pipelines, and maintain 30 days of reverse replication after the DNS switch so you always have a safe rollback.

Sources

• Regulation (EU) 2023/2854 of the European Parliament and of the Council (EU Data Act) – EUR-Lex
• European Commission – Data Act Explained (Official Policy & FAQ Page)
• Regulation (EU) 2022/2554 on Digital Operational Resilience for the Financial Sector (DORA) – EUR-Lex

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

Migrating from AWS to UpCloud is straightforward for companies running standard web architectures built on virtual machines, Kubernetes, relational databases, and S3-compatible object storage. Most core compute, storage, and networking resources map directly between the two platforms, while proprietary AWS services like DynamoDB, SQS, or Lambda require replacing with open-source equivalents or container workloads. Companies making this move typically reduce their monthly cloud spend by eliminating outbound data transfer fees, avoiding Kubernetes control plane charges, and switching to predictable, bundled server pricing.

Key takeaways

• Direct infrastructure mapping: EC2, RDS (PostgreSQL and MySQL), ElastiCache, S3, EKS, and Application Load Balancers all have direct managed equivalents on UpCloud.
• True European jurisdiction: UpCloud is headquartered in Helsinki, Finland, operating under EU and Finnish law rather than US extraterritorial jurisdiction.
• Predictable cost structure: UpCloud includes storage and outbound data transfer (under a Fair Transfer Policy) in its server plans, removing two of the most unpredictable items on an AWS bill.
• Proprietary services need adjustment: Workloads relying heavily on AWS Lambda, SQS, or DynamoDB must be refactored to run on containers, self-managed queues, or standard databases before or during the move.
• Egress fees for switching are regulated: Under the EU Data Act, cloud providers can charge no more than their actual cost for switching egress until January 12, 2027, when switching charges are banned altogether.

Why European companies move from AWS to UpCloud

For most 10-to-300-person European companies, AWS offers far more services than the engineering team actually uses. You pay a premium—both in monthly invoices and in cognitive load—for a catalog of over 200 services when your application only needs compute, a relational database, a Redis-compatible cache, and object storage.

Three practical reasons usually trigger a move to UpCloud:

1. Cost predictability: AWS bills are composite. A single virtual machine involves separate charges for the EC2 instance, the EBS root volume, provisioned IOPS, public IPv4 addresses, NAT Gateway hourly fees,NAT Gateway data processing fees, and outbound internet traffic. UpCloud bundles CPU, memory, high-speed MaxIOPS block storage, and outbound data transfer into a single flat rate.
2. Data sovereignty and compliance: UpCloud Ltd is a Finnish company. While AWS offers EU regions and an AWS European Sovereign Cloud that keeps data and operations inside the EU, Amazon remains a US parent corporation subject to the US CLOUD Act. For teams bound by strict customer contracts or regulations like DORA (Regulation (EU) 2022/2554), moving to an EU-owned provider simplifies compliance and risk assessments.
3. Right-sized operational complexity: Managing AWS IAM policies, VPC route tables, and multi-layered security rules takes dedicated specialist time. UpCloud provides a cleaner API, native Terraform and OpenTofu providers, and straightforward private networking without losing production essentials.

Service mapping: what moves directly

If your stack is built on open standards or Linux primitives, migrating from AWS to UpCloud is mostly an infrastructure-as-code translation exercise.

Compute and Block Storage

On AWS, you choose between dozens of instance families (t3, m6i, c7g) and configure EBS volumes separately. As of 2026, UpCloud organizes its general compute primarily around Starter plans (aimed at development, testing, and lighter workloads), Premium plans (built on AMD EPYC hardware with bundled MaxIOPS storage for production), and Cloud Native plans (designed for Kubernetes and container nodes where you size storage separately). UpCloud also offers dedicated GPU servers for machine learning workloads.

Managed Databases and Caches

AWS RDS for PostgreSQL and MySQL map directly to UpCloud Managed Databases. UpCloud handles automated backups, point-in-time recovery, minor version upgrades, and high-availability failover. For caching, AWS ElastiCache users move to UpCloud Managed Valkey. Because Valkey maintains wire-protocol compatibility with Redis, your application libraries (ioredis, redis-py, go-redis) work by simply changing the connection string.

Kubernetes (EKS to UKS)

Migrating from Amazon EKS to UpCloud Kubernetes Service (UKS) often removes significant glue code. EKS relies heavily on AWS-specific IAM Roles for Service Accounts (IRSA), the AWS Load Balancer Controller, and the EBS CSI driver. On UKS, the UpCloud Container Storage Interface (CSI) and Cloud Controller Manager are pre-configured, so creating a standard Kubernetes PersistentVolumeClaim or a Service of type LoadBalancer automatically provisions UpCloud block storage or a Managed Load Balancer.

What changes in your architecture

Not every part of an AWS account has a 1-to-1 button on UpCloud. When planning your migration, expect to adjust the following areas.

1. Identity and Access Management (IAM)

AWS uses IAM not just for human users, but as a service-to-service authentication fabric (for example, allowing an EC2 instance role to write to an S3 bucket without static keys). UpCloud supports sub-accounts, workspace permissions, API tokens, and S3 user access policies, but it does not replicate AWS's cross-service IAM role assumption.

• What to change: Use S3 access keys stored in secret managers or Kubernetes Secrets for Object Storage access, and rely on private SDN networks and firewall rules to restrict database and cache traffic to authorized compute nodes.

2. Queues, Emails, and Serverless Functions

UpCloud focuses on core infrastructure (IaaS) and essential managed platforms (PaaS) rather than application-layer microservices. It does not offer native equivalents to AWS SQS, SNS, SES, or Lambda.

• Serverless functions (Lambda): Most teams package their Node.js, Python, or Go functions as lightweight HTTP containers and deploy them onto their UKS cluster or a small Cloud Server, triggering them via standard cron jobs or webhooks.
• Message queues (SQS/SNS): If you use queues for background jobs, you can move the queue workload onto your UpCloud Managed Valkey instance (using BullMQ, Sidekiq, or Celery) or run RabbitMQ / NATS on your Kubernetes cluster.
• Transactional email (SES): Point your application to a dedicated European email provider (such as Scaleway Transactional Email or Mailjet) via standard SMTP or REST API.

3. Proprietary Databases and Warehouses

Workloads tied to Amazon DynamoDB, Aurora Serverless features, or Amazon Redshift cannot be lifted and shifted without code changes. If DynamoDB is used simply as a key-value store or session cache, it can often be replaced with PostgreSQL (using JSONB columns) or Valkey. If your entire application data model is built around single-table DynamoDB designs, you will need a dedicated refactoring project before moving.

4. DNS and CDN

UpCloud does not operate an authoritative DNS service equivalent to Route 53, though it is rolling out its own Content Delivery Network. Most engineering teams keep DNS on an independent provider (like Cloudflare or DNSimple) or another European provider. Keeping DNS independent of your compute provider is good operational practice anyway, as it makes traffic switching and multi-cloud rollbacks much easier.

What it costs: AWS vs. UpCloud in 2026

Cloud pricing changes frequently, so you should always verify current numbers on the official AWS and UpCloud pricing pages. However, comparing the pricing structures as of 2026 highlights why bills look so different on the two platforms.

Compute and Storage Pricing

On AWS (eu-central-1, Frankfurt), a standard production general-purpose instance like an m6i.xlarge (4 vCPUs, 16 GB RAM) costs approximately $180 to $190 per month on-demand, before adding EBS storage (roughly $0.09/GB-month for gp3) and public IPv4 fees (approximately $3.65/month per IP).

On UpCloud, as of 2026, compute is priced in flat tiers with storage included:

• Starter plans (for dev/test and lighter workloads) start at approximately €3/month (1 vCPU, 1 GB RAM, 10 GB storage) and run up to €28/month for 4 vCPUs, 16 GB RAM, and 50 GB storage.
• Premium plans (AMD EPYC production hardware with MaxIOPS storage) start at approximately €5/month. A production server with 4 CPU cores, 8 GB RAM, and 100 GB of MaxIOPS storage costs approximately €52/month, while 4 CPU cores, 16 GB RAM, and 150 GB of storage is approximately €92/month (excluding VAT).

The Hidden Multipliers: Egress and Control Planes

Where European companies usually see the biggest savings is not raw CPU cost, but the elimination of AWS overhead fees:

• Data egress (outbound traffic): AWS charges roughly $0.09 per GB for data transferred out to the internet after the first 100 GB, plus cross-AZ transfer fees ($0.01/GB in each direction) when instances talk to databases or load balancers in different Availability Zones. UpCloud includes zero-cost egress across its plans under a generous Fair Transfer Policy, and private SDN traffic between your servers within a data center is free.
• Kubernetes control plane: AWS charges $0.10 per hour (approximately $73/month) per EKS cluster just for the control plane—if you run separate dev, staging, and production clusters, that is over $215/month before booting a single worker node. UpCloud includes the UKS control plane at no additional cost as part of its "UpCloud Essentials" offering; you only pay for the worker nodes, load balancers, and storage you attach.
• One-time migration egress fees: Historically, AWS charged steep data transfer fees when copying terabytes of S3 data and database snapshots out to another provider. Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers may charge no more than their actual incurred cost for data egress when a customer is switching providers until January 12, 2027. Starting January 12, 2027, switching charges—including data egress fees for switching—are completely banned across the EU.

Pre-migration checklist: how to execute the move

A disciplined migration avoids "big bang" rewrites. Build the new environment alongside the old one, synchronize the data, and switch traffic only when both environments match.

1. Audit your AWS bill and state: Export your last three AWS bills and your Terraform state. Flag any proprietary services (SQS, Lambda, SES) and decide how you will replace them before touching production.
2. Choose your UpCloud region: Select a European data center close to your users—such as Frankfurt (de-fra1), Amsterdam (nl-ams1), Helsinki (fi-hel1 / fi-hel2), Madrid (es-mad1), Warsaw (pl-waw1), Stockholm (se-sto1), Copenhagen, or Oslo.
3. Rebuild infrastructure as code: Write new Terraform or OpenTofu configurations using the official UpCloudLtd/upcloud provider to provision SDN private networks, firewall rules, UKS clusters or Cloud Servers, and Managed Databases.
4. Update CI/CD pipelines: Duplicate your GitHub Actions or GitLab CI deployment jobs so your team can deploy the exact same application build to both AWS and UpCloud simultaneously.
5. Sync Object Storage: Use rclone or S3 migration tooling to copy objects from AWS S3 to UpCloud Managed Object Storage. Run periodic delta syncs with checksum verification to capture newly uploaded files.
6. Set up live database replication: Configure logical replication from AWS RDS to UpCloud Managed Databases. This allows your UpCloud database to stay within seconds of your live AWS production database without taking your app offline.
7. Lower DNS TTLs: At least 48 hours before cutover, reduce the Time-To-Live (TTL) on your DNS records to 60 seconds.
8. Cut over with a short write pause: During a low-traffic window, put the AWS application into maintenance (read-only) mode, verify that database replication lag is zero, run a final object storage delta sync, promote the UpCloud database to primary, and update your DNS records to point to your UpCloud Load Balancer.
9. Keep a rollback window: Do not delete your AWS environment on day one. Keep reverse replication or snapshots running for two to four weeks until your team is confident in the new setup, then decommission the AWS resources.

Frequently asked questions

Does UpCloud support multi-AZ deployments like AWS?

UpCloud approaches availability differently than AWS. Instead of splitting every city into three separate Availability Zones and charging for cross-AZ traffic, UpCloud builds high redundancy directly into each data center (including triple-replicated MaxIOPS storage over InfiniBand and redundant networking) backed by a 99.99% uptime SLA. For Managed Databases and Managed Load Balancers, you can select multi-node High Availability plans that automatically handle node failures. For disaster recovery across physical locations, you can replicate across UpCloud's multiple European data centers.

Do we need to rewrite our applications to move from S3 to UpCloud Object Storage?

No. UpCloud Managed Object Storage is S3-compatible. You keep using the official AWS SDKs (@aws-sdk/client-s3, boto3, etc.) in your application code. You only need to change the endpoint configuration parameter to point to your UpCloud Object Storage URL and update your access key and secret key.

How long does a typical AWS to UpCloud migration take?

For a company with 10 to 300 employees running a standard web stack (VMs or Kubernetes, PostgreSQL/MySQL, Redis, and S3), the end-to-end process typically takes between two and four weeks. Most of that calendar time is spent testing the staging environment, updating CI/CD pipelines, and letting large initial data transfers complete in the background. The actual production cutover pause usually takes between 5 and 30 minutes.

What happens to our AWS Reserved Instances or Savings Plans?

If you have active 1-year or 3-year AWS Savings Plans or Reserved Instances, you remain financially committed to those hourly payments until the term expires (though some standard EC2 Reserved Instances can be listed on the AWS RI Marketplace). Before migrating, check the expiration dates in AWS Cost Explorer. Even with an active commitment, some companies move part of their workload early to eliminate high AWS NAT Gateway and data egress charges.

How MoveInfra can help

MoveInfra moves European companies from AWS to UpCloud—our default EU cloud target—for a fixed price. We analyze your AWS bill and read-only cloud metadata, rebuild your environment on UpCloud as clean Terraform code, and synchronize your RDS databases and S3 buckets in the background via logical replication and checksummed clones. Your team points your existing CI/CD pipelines to the new environment, and we execute the DNS switch when replication lag is under five seconds, keeping reverse replication active for 30 days so you always have a safe rollback.

Sources

• UpCloud Pricing and Server Plans
• UpCloud Documentation: Managed Databases, Kubernetes, and Object Storage
• Regulation (EU) 2023/2854 (EU Data Act) on EUR-Lex
• Regulation (EU) 2022/2554 (Digital Operational Resilience Act - DORA) on EUR-Lex
• Amazon EC2 On-Demand Pricing

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

Moving from AWS to Hetzner gives European companies much lower compute and network costs, predictable monthly billing, and strict German legal jurisdiction, while requiring engineering teams to self-manage services that AWS runs for them. Hetzner provides core infrastructure building blocks—including virtual servers, dedicated bare-metal machines, block volumes, S3-compatible object storage, private networks, firewalls, and load balancers—at a fraction of hyperscaler prices. However, Hetzner does not offer managed relational databases (like AWS RDS), managed Kubernetes (like Amazon EKS), managed caching (like ElastiCache), or serverless queues and functions. If your architecture relies on these services, migrating to Hetzner means deploying and operating them yourself on virtual or dedicated servers, or choosing another European provider that offers managed platform services.

Key takeaways

• Substantial cost reductions on compute and egress: Hetzner bundles generous outbound data transfer (typically 20 TB per server in European locations) and charges a single flat rate for compute, removing the complex per-gigabyte NAT gateway and egress fees common on AWS.
• True European jurisdiction: Hetzner Online GmbH is headquartered in Germany and operates data centers in Nuremberg and Falkenstein (Germany) and Helsinki (Finland), keeping your infrastructure outside the reach of US extraterritorial laws.
• No managed databases or Kubernetes: Unlike AWS, Hetzner focuses strictly on Infrastructure as a Service (IaaS). You must run PostgreSQL, MySQL, Redis, and Kubernetes on your own cloud or dedicated instances using open-source tools and automation.
• Simpler networking and permissions: You trade AWS's sprawling IAM policies and multi-layered VPC billing for straightforward cloud firewalls, private networks, and project-based API tokens.
• Regulatory tailwinds for switching: Under the EU Data Act (Regulation (EU) 2023/2854), cloud providers can charge no more than their direct cost for switching egress until January 12, 2027, after which switching fees are banned completely.

Why European companies move from AWS to Hetzner

For most 10-to-300-person companies in Europe, the initial push to evaluate Hetzner comes from looking at the monthly AWS bill. On AWS, compute is rarely the only major expense. Costs accumulate through managed service premiums, per-gigabyte charges for traffic passing through NAT gateways, cross-availability-zone data transfer fees, and outbound internet egress.

Hetzner structures its pricing around flat, predictable resource usage. Whether you rent shared-CPU virtual machines, dedicated-CPU cloud instances, or physical bare-metal servers through Hetzner Robot, the monthly ceiling is clear. In European regions, cloud servers include 20 TB of outbound traffic per month at no additional charge, and internal traffic over Hetzner Private Networks is free. You should always check Hetzner's official pricing page for current figures, especially following their June 2026 price adjustments on dedicated hardware, as exact numbers depend on server generation and location.

The second driver is legal and operational sovereignty. Even if you deploy workloads in the AWS Frankfurt (eu-central-1) region or use the AWS European Sovereign Cloud, the underlying provider remains Amazon, a US corporation subject to the US CLOUD Act. Hetzner Online GmbH is a privately owned German company founded in 1997. When you host in its German or Finnish data centers, both the physical hardware and the corporate parent fall strictly under EU and national law. For companies subject to strict GDPR interpretations by enterprise customers, or financial entities building exit strategies under the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), moving to a domestic European provider simplifies compliance audits.

Finally, there is engineering clarity. AWS offers over two hundred services, which often leads small engineering teams to build overly complex architectures. Moving to Hetzner forces a return to standard Linux servers, containers, and open-source software that can run anywhere.

AWS to Hetzner service mapping

Before planning a migration, both technical leads and finance teams need an honest view of how AWS components translate to Hetzner. Some services map directly, while others shift operational responsibility back to your team.

What you must build and operate yourself

The financial savings on Hetzner are real, but they are not free money. A portion of what you stop paying Amazon is traded for engineering ownership. Here is what your team must be prepared to build and maintain.

1. Relational databases and high availability

On AWS RDS, enabling Multi-AZ high availability, automated point-in-time recovery (PITR), and minor version upgrades takes a few clicks. Because Hetzner does not offer managed databases, you must build this resilience on top of Hetzner Cloud VMs or dedicated servers.

In a production environment, you should not simply run a single apt install postgresql instance without safeguards. To match RDS reliability, teams typically deploy a two- or three-node cluster managed by open-source orchestrators like Patroni (with etcd or Consul for consensus), or use automated provisioning stacks. You must also configure continuous Write-Ahead Log (WAL) archiving and daily base backups using tools like pgBackRest or WAL-G, pushing encrypted backups to Hetzner Object Storage (or an external backup destination). Crucially, you must test restoring these backups regularly.

2. Kubernetes or container orchestration

If you run microservices on Amazon EKS or AWS Fargate, moving to Hetzner means taking over the Kubernetes control plane. While EKS manages the API servers and etcd nodes for you, on Hetzner you will run both control-plane nodes and worker nodes on your own virtual machines.

Fortunately, the open-source ecosystem around Hetzner is mature. Many European teams run lightweight distributions like k3s or immutable Kubernetes operating systems like Talos Linux on Hetzner Cloud. Hetzner maintains official open-source integrations that make Kubernetes behave like a native cloud environment:

• Hetzner Cloud Controller Manager (HCCM): Automatically provisions Hetzner Load Balancers when you create a Kubernetes Service of type LoadBalancer and configures private network routing between nodes.
• Container Storage Interface (CSI) Driver: Automatically creates, attaches, and resizes Hetzner Cloud Volumes when your pods request PersistentVolumeClaims.
• Cluster Autoscaler: Adds or removes Hetzner worker VMs based on pending pod resource requests.

Even with these drivers, your team remains responsible for upgrading Kubernetes versions, rotating certificates, and monitoring etcd health.

3. Caching, queues, and background jobs

Many AWS architectures rely heavily on SQS for decoupling services, Lambda for cron jobs and webhooks, and ElastiCache for session storage. When moving to Hetzner, architectural simplification helps a great deal.

Instead of replacing every AWS primitive with a separate distributed system, evaluate whether your existing stack can absorb the workload. For example, if you run PostgreSQL, tools like pg-boss (Node.js), Oban (Elixir), or Solid Queue (Ruby) let you run reliable background jobs directly inside your database, removing the need for a separate SQS replacement. If you need high-throughput message brokering or caching, you will need to provision dedicated VMs running Valkey, Redis, or RabbitMQ via Terraform and Ansible, wired into your monitoring stack.

4. Observability, logging, and alerting

Without AWS CloudWatch collecting logs and metrics by default, you need a self-hosted or third-party observability stack. On Hetzner, teams normally deploy the Prometheus and Grafana stack (alongside node_exporter and Loki for logs) on a dedicated monitoring VM, or ship telemetry to a European-hosted observability service. You will also need to configure alert routing (via Alertmanager or similar) to wake up your on-call engineers if a disk fills up or a database node fails over.

5. Access control and secret management

AWS IAM lets you restrict a specific server to reading a single S3 bucket or writing to one DynamoDB table. Hetzner's Cloud API uses bearer tokens that grant access to an entire project. This means you must be careful about where you place Hetzner API keys (such as inside your Kubernetes cluster for the CSI driver). For application secrets that previously lived in AWS Secrets Manager or SSM Parameter Store, you will need to adopt encrypted secrets in Git (using SOPS or Sealed Secrets), use your CI/CD platform's secret injection, or host a vault service like HashiCorp Vault or OpenBao.

When Hetzner is the right choice (and when to pick another EU cloud)

Hetzner is an exceptional fit if:

• Your team has at least one engineer comfortable with Linux administration, Terraform, and Docker or Kubernetes.
• You run compute-heavy, memory-heavy, or bandwidth-heavy workloads where AWS costs scale poorly.
• Your architecture is relatively clean—such as a monolithic web application or a sensible set of containerized services backed by PostgreSQL, Redis, and S3 object storage.

However, if your company has no dedicated DevOps or platform engineering capacity, and leadership does not want engineers spending time maintaining database replication or Kubernetes upgrades, Hetzner may require too much operational overhead. In that case, you do not have to stay on AWS. Other European cloud providers—such as UpCloud, Scaleway, or OVHcloud—offer managed PostgreSQL/MySQL databases and managed Kubernetes control planes out of the box. You will pay more per CPU core on those platforms than on Hetzner, but still generally less than on AWS, while keeping managed database convenience under European jurisdiction.

Practical migration checklist: AWS to Hetzner

If you decide to move to Hetzner, follow a structured process to keep downtime to a minimum and preserve a clean rollback path.

1. Audit your AWS footprint and egress: List every active resource across your AWS regions. Identify hidden dependencies like Lambda functions triggered by S3 events, hard-coded IAM role assumptions (sts:AssumeRole), and proprietary databases like DynamoDB. Note that under Article 29 of the EU Data Act, you can request switching terms from AWS where data egress fees are capped at direct cost until January 12, 2027, and eliminated thereafter.
2. Define your Hetzner architecture in Terraform: Do not click around in the Hetzner Cloud Console to build production. Use the official hcloud Terraform provider to define your private networks, firewalls, load balancers, and compute nodes. Set up automated configuration management (such as Ansible or cloud-init) to bootstrap your database clusters and container hosts.
3. Clone object storage with checksums: Create your buckets in Hetzner Object Storage. Use an S3 synchronization tool like rclone to copy objects from AWS S3 to Hetzner, verifying file integrity with checksums. Keep periodic syncs running until cutover day.
4. Establish live database replication: Rather than taking a multi-hour downtime window to dump and restore your database, set up logical replication from AWS RDS to your new PostgreSQL or MySQL cluster on Hetzner. Connect the two environments over an encrypted VPN tunnel (such as WireGuard) so your Hetzner database stays within seconds of your live AWS database.
5. Update your CI/CD pipelines: Adjust your GitHub Actions or GitLab CI workflows to deploy your application containers to the new Hetzner environment in parallel with AWS. Run end-to-end tests against the Hetzner staging endpoints.
6. Lower DNS TTLs and execute the switch: A few days before migration, lower your DNS Time-To-Live (TTL) values to 60 seconds. During a planned low-traffic window, put your application into a brief maintenance/read-only mode, verify that database replication lag is zero, run a final S3 sync, promote the Hetzner database to primary, and update your DNS records to point to the Hetzner Load Balancer.
7. Maintain a rollback option before cleanup: Keep your old AWS environment running and configure reverse replication from Hetzner back to AWS if possible, or maintain snapshots for at least 30 days. Once everything runs smoothly through a full monthly billing cycle, decommission your AWS resources.

Frequently asked questions

Does Hetzner have an equivalent to AWS S3?

Yes. Hetzner offers native, S3-compatible Object Storage. You can interact with it using the standard AWS CLI, SDKs, or Terraform providers by changing the endpoint URL to Hetzner's regional object storage endpoint. It supports standard bucket operations, access keys, and public/private visibility, though it does not include AWS-specific extensions like S3 Glacier archival tiers or EventBridge notifications.

How do we handle high-availability databases on Hetzner without RDS?

Because Hetzner does not sell a managed database service, high availability is achieved by provisioning multiple Hetzner Cloud VMs across different physical availability zones or data center locations, attached to local NVMe disks or Cloud Volumes. You then run an automated failover manager like Patroni for PostgreSQL, combined with automated backup tools (such as pgBackRest) that stream backups continuously to S3-compatible object storage.

Can we mix Hetzner Cloud VMs and Dedicated Servers in the same network?

Yes. Through the Hetzner vSwitch feature, you can connect dedicated bare-metal servers from Hetzner Robot directly into your Hetzner Cloud Private Networks. This allows teams to run stateless web applications on flexible Cloud VMs while placing heavy, predictable database workloads on high-performance bare-metal NVMe servers over private internal IPs.

Will we have to pay huge AWS data egress fees when moving our data to Hetzner?

Data egress fees are shrinking due to European regulation. Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers operating in the EU may only charge the direct cost incurred for switching data egress until January 12, 2027, and from January 12, 2027 onward, all switching charges—including data egress fees when moving to another provider—are banned. Furthermore, AWS offers a specific fee waiver program for customers permanently migrating off the platform under the Data Act framework.

How MoveInfra can help

If you want Hetzner's low monthly costs and German jurisdiction without spending weeks building database clusters, Kubernetes control planes, and migration scripts from scratch, MoveInfra handles the transition for a fixed price. We analyze your current AWS footprint, rebuild your infrastructure on Hetzner as clean Terraform code—setting up production-ready databases and Kubernetes directly on Hetzner servers—and synchronize your live data via logical replication and checksummed object storage clones. After we help point your CI/CD pipelines to the new environment and switch DNS during a brief planned write pause, we maintain reverse replication for 30 days so you have a safe rollback path before shutting down AWS.

Sources

• Regulation (EU) 2023/2854 (EU Data Act) on EUR-Lex
• Regulation (EU) 2022/2554 (DORA) on EUR-Lex
• Hetzner Official Documentation (Hetzner Docs)
• Hetzner Cloud Product and Pricing Overview
• Hetzner Cloud API Reference

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.