The Hard Part of Leaving AWS: How to Move Your Databases and Object Storage to European Cloud

Moving your web application from AWS, Google Cloud, or Azure to a European cloud provider like Scaleway, OVHcloud, or Hetzner has become a strategic priority for many companies. Digital sovereignty, GDPR compliance, and predictable pricing drive these decisions.

The easy part is migrating stateless services – usually just redirecting your CI/CD pipeline to a new Kubernetes cluster. The real challenge lies in moving your application’s state: databases, object storage, and persistent volumes. Data has gravity, and moving it requires careful planning.

This guide walks you through the technical steps to migrate your stateful components safely while minimizing downtime and preventing data loss.

Map Your Current State

Before moving any data, you need to understand exactly what you have. Hyperscalers often hide state behind managed services, creating subtle vendor lock-in.

The biggest challenge is identifying proprietary features. Are you using standard PostgreSQL, or do you depend on AWS Aurora’s serverless scaling? Do your storage buckets rely heavily on proprietary lifecycle rules?

Start by cataloging every database instance, caching layer (Redis/Memcached), and object storage bucket. Then standardize by downgrading or adapting proprietary features to open-source equivalents. If you’re migrating a database, make sure your target European cloud offers a compatible managed version or prepare to self-host on standard compute instances.

Calculate your total data volume and current egress fees. This helps you plan your migration window based on available bandwidth.

Move Object Storage First

Object storage typically holds the largest volume of data – user uploads, backups, and static assets can easily reach terabytes. The challenge is transferring this data efficiently without disrupting ongoing uploads while managing network timeouts and egress costs.

Most European cloud providers offer S3 API compatibility, so you can use synchronization tools effectively. Use a robust, multi-threaded transfer tool like rclone for the initial sync:

rclone sync source:my-bucket dest:my-eu-bucket --transfers=32 --checkers=64 --fast-list

Since the initial sync may take days, your application will keep writing new files to the hyperscaler. Schedule delta syncs daily, then hourly as you approach cutover. Just before the final switch, update your application to dual-write new objects to both locations simultaneously.

Migrate Your Database Carefully

Databases require the most precision since inconsistency means immediate application failure. The challenge is minimizing downtime. A simple dump and restore works for small datasets under 10GB but causes unacceptable downtime for larger, high-traffic databases.

For smaller workloads, you can use a maintenance window approach. Put your app in read-only mode, run pg_dump or mysqldump, transfer the file via scp or a secure tunnel, and restore it on the new European provider.

For high-availability workloads, implement logical replication for near-zero downtime. Set up a secure VPN or SSH tunnel between your hyperscaler VPC and your new European cloud network. Enable logical replication on the source database (setting wal_level = logical in PostgreSQL). Create a publication on the hyperscaler database and a subscription on the new European managed database. Wait for the destination to catch up until replication lag drops to near zero.

Handle Caches and Session Data

Not all state needs migration. Redis caches and session stores are often transient, but you need to decide carefully. Cold caches can create a “thundering herd” problem that overwhelms your newly migrated database.

If your cache holds easily reproducible data, spin up a fresh Redis instance in the European cloud and let it warm up naturally. If a cold cache would crash your database, perform a manual migration using Redis BGSAVE to create an .rdb dump file, then transfer and restore it in your new environment.

Execute the Final Cutover

The actual transition requires careful timing and monitoring.

Start by lowering your DNS Time-To-Live to 60 seconds 48 hours before cutover. This ensures users get routed to new servers almost instantly when you switch IP addresses.

Put your hyperscaler application into brief read-only mode to stop new writes. Run one final rclone sync for object storage and wait for database replication lag to hit zero.

Promote your European cloud database to primary and terminate the replication from the hyperscaler. Update your DNS records to point to your new load balancers.

Monitor your application logs and performance metrics closely. Keep the hyperscaler environment intact but dormant for at least a week as a fallback option.

Migrating from a hyperscaler to European cloud infrastructure is a complex technical challenge, but it’s entirely manageable with proper planning. Using standardized tools like rclone, leveraging native database replication, and executing a well-rehearsed cutover strategy lets you reclaim data sovereignty, reduce vendor lock-in, and gain the regulatory benefits of European infrastructure.