Leaving Google Cloud for an EU-owned provider: a practical plan

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:

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.
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.
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.

Google Cloud Service	Open Standard / Underlying Tech	EU Cloud Equivalent (UpCloud, Scaleway, OVHcloud, etc.)	Migration Complexity
Compute Engine (GCE)	KVM / Linux / Windows VMs	Cloud Servers / Instances	Low. Rebuild via Terraform and deploy via CI/CD.
Google Kubernetes Engine (GKE)	Kubernetes	Managed Kubernetes (or self-hosted on VMs for Hetzner)	Low to Medium. Replace GCP-specific ingress annotations and workload identity.
Cloud SQL	PostgreSQL, MySQL	Managed PostgreSQL / MySQL	Low. Sync using native logical replication.
Cloud Storage (GCS)	Object storage (S3 interoperability)	S3-compatible Object Storage	Low. Clone buckets with checksum verification.
Memorystore	Redis / Valkey	Managed Redis / Valkey	Low. Usually rebuilt empty as a cache or synced via replication.
Cloud Load Balancing	HTTP(S) / TCP Proxy	Managed Load Balancers	Low. Recreate routing rules and TLS certificates.
Cloud Run	Knative / Containers	Serverless Containers (Scaleway) or Kubernetes / VMs	Medium. Package containers to run on K8s or standard container runners.
Cloud Functions	Event-driven functions	Serverless Functions (Scaleway) or worker processes	Medium. HTTP triggers move easily; GCP event triggers require code edits.
Pub/Sub	Message queueing	Managed NATS/RabbitMQ/Kafka or self-hosted queues	Medium. Requires updating client SDKs in application code.
Firestore / Bigtable / Spanner	Proprietary NoSQL / NewSQL	Self-managed MongoDB/Cassandra or refactor to PostgreSQL	High. Requires schema migration and application data-layer rewrites.
BigQuery	Proprietary Data Warehouse	ClickHouse / PostgreSQL, or leave in place temporarily	High. Requires rewriting SQL pipelines and BI connectors.

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:

Submit a formal “Exit Notice” form through Google Cloud support before starting the bulk transfer.
Wait for Google to assign a Billing Support agent (which takes up to 14 days).
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.

Put your application on Google Cloud into maintenance or read-only mode to pause new database writes.
Wait a few seconds for the final transactions to replicate to the EU database, and run a final delta sync on object storage.
Promote the EU database to primary (read-write) and enable your background workers in the EU environment.
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.