Migrating from AWS to Hetzner: the realistic guide

The internet is full of "AWS to Hetzner in a weekend!" articles. For a hobby project, that's even true. For a company with paying customers, SLAs and a database whose loss would be existential, it's reckless. Here's the sequence as it actually looks in serious projects — including the parts that hurt.

Phase 0: the inventory (that almost everyone skips)

Before anything gets migrated, you need complete answers to three questions: What runs? What talks to what? What costs what? Sounds trivial — but AWS accounts grown over four years almost always contain surprises: forgotten instances, orphaned EBS volumes, Elastic IPs for long-dead services, a Lambda hitting a dead API every hour since 2023.

• Analyse Cost Explorer by service and tag — the bill is the most honest inventory list
• Map all services with dependencies (who talks to RDS? what reads from S3? which IAM roles exist and why?)
• Flag "zombie infrastructure": in our projects, 5–15 % of the bill can simply be deleted — before any migration

Phase 1: the service mapping

Every AWS service gets a destination: a Hetzner equivalent, a self-hosted solution — or the honest classification "stays for now". The short version for the most common cases:

• EC2 → Hetzner Cloud / dedicated servers. The easy part. Rule of thumb from practice: the same performance for a fraction of the price, dedicated vCPUs included.
• RDS (PostgreSQL/MySQL) → self-run or HA with Patroni. Hetzner has no RDS-style managed database — this is the most important architecture decision of the whole migration. Options: a dedicated DB server with a clean backup concept (surprisingly often enough), a Patroni cluster for real HA, or managed PostgreSQL at a second EU provider.
• S3 → Hetzner Object Storage. S3-compatible API: usually a new endpoint plus rclone sync for the data. Watch out for event notifications or lifecycle rules — those need replacements.
• ELB/ALB → Hetzner Load Balancer plus Traefik/Nginx for routing, cert-manager for TLS.
• Lambda/SQS/EventBridge → container workers + NATS/RabbitMQ. The most expensive item. Honest statement: if you're deep in the serverless ecosystem, you don't migrate here — you rebuild. It can still pay off, but budget it as a rebuild, not a move.

The full translation table — including Cognito, CloudWatch, Secrets Manager & co. — lives on the alternatives page.

Phase 2: build the target environment as code

The new environment is built in parallel — as Terraform/Ansible code, not as a clicking session. It takes longer at first, and that's exactly why it's right: from now on every change is reproducible, every environment (staging = production) identical, and rollback is a matter of minutes, not archaeology. How we structure such environments is on our deployment page.

Phase 3: sync data & run in parallel

1. Set up database replication: logical replication (PostgreSQL) or replica + sync to the new environment. Goal: the new DB trails the old one by seconds.
2. Object storage sync: initial full rclone pass (for terabytes: plan days — budget the one-off AWS egress fees), then delta syncs.
3. Test staging under real load: traffic replay or shadow traffic against the new environment. Load tests, failover tests, a restore test of the new backup concept — before cutover, not after.
4. Lower DNS TTL (e.g. to 300 seconds), days before cutover — the least spectacular step with the biggest impact on switchover time.

Phase 4: the cutover

If everything before was clean, the cutover itself is almost boring — and that's exactly how it should be: briefly pause writes, final database sync, switch DNS, watch the health checks. In well-prepared projects we're talking about a maintenance window of minutes — or none. The old AWS environment stays frozen for another two to four weeks afterwards: it is the rollback plan.

The five most common mistakes (that we get to clean up)

1. Big bang instead of parallel operation. "We'll switch on Saturday" works until the first surprise — and it always comes. Parallel operation costs a few weeks of double infrastructure and saves sleepless nights.
2. Underestimating the database. 90 % of migration downtime happens around the database. Planning with "dump and restore will do" means planning your maintenance window in hours instead of minutes.
3. Forgetting egress costs. AWS charges for data leaving. For large S3 buckets that's a real one-off item that belongs in the business case — and afterwards, egress is a solved topic forever.
4. Missing IAM dependencies. Applications that implicitly call AWS APIs via instance roles only surface in the new environment — search the codebase for SDK calls during inventory.
5. Not settling operations. Hetzner won't run your database for you. Without an answer to "who patches, who monitors, who gets woken at night?", savings turn into risk. Options: your team, a partner, Hygge Care.

What does it cost — and what does it return?

Realistic ballparks from typical projects: migration projects for startup/SME setups range from €15,000 to €80,000 (depending on complexity, mainly the serverless share and database requirements). Against that stand ongoing savings of usually 50–70 % of infrastructure costs — putting break-even frequently under a year. For a first estimate with your numbers: our cost calculator, no signup.