47 services to EKS. Eight waves.
Zero customer-facing downtime.

The situation: third attempt, hard deadline

The marketplace ran a monolithic PHP stack on EC2 behind a classic load balancer, deploying twice a week through a process everyone was afraid of. The board wanted microservices on Kubernetes before the flagship sale; engineering wanted to stop shipping at walking pace. Two previous attempts with another vendor had both died the same death: user sessions lived in local application state, so every cutover attempt logged customers out mid-cart, and every rollback was a fire drill.

That failure pattern is the first of the three Kubernetes migration mistakes we keep meeting: migrating the platform before de-coupling the state. The third attempt was scoped to fix the root cause first and move traffic second.

What we did, wave by wave

The wave discipline is the method. A big-bang cutover stakes the whole business on one night going well; eight small waves mean the worst possible outcome at any point is one service's traffic sliding back to a fleet that's still warm. It costs more in duplicated infrastructure for a few weeks — we said so up front — and it's why the downtime line reads zero. The trade-offs are the same ones we walk through in managed vs self-hosted Kubernetes.

What the pre-wave load tests caught

Testing every wave at 3x observed peak is expensive discipline, and it pays for itself the first time it catches what would have been a sale-day outage. Two catches were typical of the class. First, connection-pool exhaustion: services that had shared a monolith's database pool now each brought their own, and the arithmetic that worked for one process at fifty connections stopped working for forty-seven services under load — found at simulated peak, fixed with PgBouncer-style pooling in front of the database, invisible to customers. Second, a hot cache keyspace: the cart service's most active keys concentrated on one Redis shard under load in a way steady-state traffic never revealed. Both fixes shipped before the wave that would have exposed them. That's the entire argument for load-testing waves instead of hoping: production traffic eventually runs the same test, but it doesn't file a ticket first.

Equally deliberate was what didn't move. The relational database stayed on RDS — a Kubernetes migration is not improved by dragging a stateful database onto the cluster mid-flight, whatever the conference talks say. Two batch workloads with no scaling problem stayed on EC2 until after the sale. Scope discipline is unfashionable and it is why the timeline held: the goal was a marketplace that survives its biggest day, not a purity certificate.

The deploy-frequency jump — 2 a week to 4 a day — wasn't a target, it was a symptom. Once Argo CD made every deploy a Git merge with automatic rollback, deploying stopped being a scheduled event with a war room and became something engineers did on a Tuesday afternoon. That cultural unlock, more than the sale-day headline, is what the client kept.

The results, sale day included

• 47 services migrated across 8 waves — on the third attempt, after two vendor failures
• Zero customer-facing downtime across the entire migration window
• Deploy frequency up 14x — from 2 per week to 4 per day, because deploys stopped being events
• 5.2x peak traffic on sale day absorbed by autoscaling with no human intervention — the pattern our e-commerce DevOps page exists for

Engagement type: Project Delivery · 16 weeks · fixed-scope SoW with milestone billing. What a cluster like this costs to run — and where the money goes — is what the Kubernetes cost calculator estimates in two minutes.

Related: Kubernetes consulting · 3 Kubernetes migration mistakes · What is Kubernetes? · Next case: 47% off an AWS bill