Consumer platform · 4M+ users
Moving production to Kubernetes without anyone noticing
A consumer app with millions of users, running on ageing virtual machines and a deployment tool nobody trusted. Migrated to Kubernetes in phases, against live traffic, with no customer-visible downtime.
The situation
A consumer platform with more than four million active users, running on auto-scaling virtual machines with a legacy deployment pipeline. Releases were slow and nerve-racking, capacity was managed by guesswork, and the infrastructure had accumulated years of undocumented decisions. The user base is concentrated in one time zone, so traffic peaks hard for four hours a night — a bad deploy has a very visible audience.
What was done
A five-phase migration to Kubernetes, moving real production traffic in increments — 3%, then 6%, 12%, 50%, 100% — using weighted DNS so that any step could be reversed in minutes. Every increment was held through a full peak-traffic night and measured before the next one was allowed.
Underneath it: the whole platform rebuilt as code. Autoscaling driven by real queue depth and CPU rather than fixed replica counts, secrets moved out of configuration files into a managed secret store, deployment by GitOps so the running state always matches the repository, and monitoring that could actually answer “is this increment worse than the last one?”
Then the old estate was decommissioned — deliberately, as its own phase, because half-migrated infrastructure is worse than either end state.
Where it ended up
No customer-visible downtime at any point. Response times unchanged through the cutover. The legacy servers and their deployment pipeline are gone, and the procedure for retiring them is written down.
The part worth stealing: ramping traffic in increments and refusing to advance until the current one is boring. It turns a migration from one big irreversible night into a series of small reversible ones.