Silhouette of a sprinter on a blue background with text about migrating a sports platform from Hetzner to AWS. Blog post label on the left.

Breaking the Limits: Migrating a High-Traffic Sports Platform from Hetzner to AWS

Every successful digital product hits a breaking point — a moment when the current infrastructure, no matter how cost-effective or well-maintained, becomes a ceiling. Our client, a fast-growing real-time sports team management platform with millions of active users, had reached that point.

This is the story of how we helped them break through it — by migrating from Hetzner to AWS, with zero downtime, and unlocking a whole new level of scalability, performance, and global readiness.

The Backdrop: Solid but Stretched

The application was already in a good place by many standards — containerized, running on Kubernetes with Rancher, hosted on Hetzner bare-metal VMs. For years, this setup served them well.

But success brings scale. And scale reveals cracks.

The core issues on Hetzner weren’t about software quality or dev practices. They were infrastructural:

Severe network limitations on Hetzner’s virtual machines.
Frequent downtime during peak hours, especially when user traffic surged globally.
Manual overprovisioning of huge on-premise instances to compensate — most of which sat idle most of the time.
Scaling databases was a major pain point. Even minor spikes risked downtime, and adding capacity wasn’t agile or automatic.

The product was strong, but the infrastructure was holding it back.

Why Move to AWS?

The decision to move wasn’t impulsive — it was born out of necessity. As our client’s business team looked toward global markets and larger-scale partnerships, they needed infrastructure that could match their ambition.

We helped them evaluate their options, and AWS stood out for several reasons:

Managed services (especially Aurora for MySQL) meant less time spent patching, tuning, and babysitting infra.
Elastic scalability with EKS allowed for dynamic, cost-efficient compute.
High availability and global footprint gave the business room to grow confidently.
Modern observability via CloudWatch and Grafana improved operational readiness.
Cloudflare integration at the edge ensured traffic handling and caching were enterprise-grade.

Most importantly, AWS gave them a platform they could rely on — not just to survive, but to thrive.

Our Migration Strategy: Seamless and Safe

As a cloud infrastructure management company, we’ve led many migrations — and we know that success isn’t just about moving fast, it’s about moving smart.

Our goal was clear: zero downtime for production.

Here’s how we did it:

Dev Environment First: We built a full mirror of the infrastructure in AWS using our Terraform modules — standard, repeatable, and automated. The development team validated that the new Aurora setup behaved exactly like their legacy MySQL setup.
Database Replication Setup: We set up MySQL → Aurora replication. Aurora was kept in read-only mode, acting as a secondary even though it was technically writable. This gave us a safety net for testing.
Production Environment Provisioned: Once replication was stable and tested, we spun up the full AWS production environment.
ProxySQL Stays in Place: ProxySQL was already being used to control database access and provide query caching. We used it to route traffic smartly during the switchover.
Workload Shift: Gradually, services were migrated to AWS EKS. Initially, the application was connected to both the legacy MySQL and Aurora, ensuring dual-read capabilities.
Final Cutover: After full confidence in Aurora, we switched it to primary and phased out the old MySQL setup entirely.

What We Gained: Beyond Just Uptime

The benefits were immediate — and significant.

Scalability: The new setup is theoretically limitless. EKS scales compute automatically, Aurora scales read replicas, and the team no longer fears growth.
Stability and Confidence: AWS gives better visibility, stronger guarantees, and battle-tested tooling. Even when issues arise, we now have the confidence and tools to handle them.
Performance: End-users noticed a faster, more responsive experience. This wasn’t just infra change — it improved the product itself.
Cost Control: Autoscaling ensured resources matched actual demand. The setup remains cost-effective, even with premium cloud services.

For the customer, this wasn’t just a backend upgrade. It was a signal that their business could now move without fear, grow into new markets, and handle anything users threw at it.

Lessons Learned (The Hard Way)

Even experienced teams hit snags.

Replication Was Tricky: Setting up MySQL → Aurora replication for a large dataset turned out to be simple conceptually, but time-consuming in reality. It took weeks to get it just right.
New Infra Brings New Bugs: Moving from underpowered VMs to autoscaling cloud environments exposed app behaviors we had never seen before. Some services failed differently or exposed hidden bugs under load.
App Changes Were Required: This wasn’t “just” an infrastructure project. Some application components had to adapt to new realities (timeouts, latency patterns, failover logic).
Don’t Skip Housekeeping: Legacy systems often have “dark corners” that rarely get exercised. Migration forces those into the light. We had to deal with edge cases and cruft that had accumulated over time.

Advice to Others

Would we recommend migrating from Hetzner to AWS? 100% — but with eyes wide open.

Plan capacity upfront — AWS has service quotas you need to lift early.
Run load tests in your new environment — behavior changes.
Involve the app team early — it’s not just about moving containers.
Clean as you go — use the migration as a chance to improve.
Partner with experience — this journey is hard to do alone.

Closing Thoughts

This migration wasn’t just about cloud. It was about unlocking the next chapter for a business ready to go global.

Hetzner got them far — but AWS gave them the runway to fly.

If you’re at the edge of what your infrastructure can handle, maybe it’s time for your next chapter too.