Zero-downtime migration to Kubernetes with multi-cloud ingress
A team moving from hand-managed VMs to Kubernetes needed it done without an outage. A staged, GitOps-driven migration with weighted ingress shifted traffic gradually and reversibly, with zero downtime.
The problem
A company on hand-managed VMs wanted Kubernetes for scaling and reproducibility but had a hard no-downtime constraint and a team nervous about a big-bang migration after past failed attempts.
The approach
- ▸Codified the target cluster and networking in Terraform so the whole environment was reproducible and reviewable instead of clicked together by hand.
- ▸Adopted GitOps with Argo CD so cluster state always matched git and any change went through a reviewable, revertible merge.
- ▸Ran the old VMs and the new cluster in parallel behind weighted ingress, shifting traffic in small increments while watching error rates and latency.
- ▸Kept every step reversible. A bad signal meant shifting weight back in seconds, not a panicked rollback at 2am.
The result
- ✓Full cutover completed with zero customer-facing downtime
- ✓Infrastructure fully reproducible from Terraform afterward
- ✓Deploys became git merges through GitOps, not manual SSH rituals
- ✓The team came away with a migration pattern they can reuse on the next service
stack: Kubernetes · Terraform · Argo CD · Envoy
Why the earlier attempts failed
The earlier attempts failed because they flipped everything at once and hoped. Running both environments in parallel behind weighted ingress turns a terrifying cutover into a dial you turn slowly while watching the graphs, and turn back the instant anything looks off. The GitOps foundation meant every change was reviewable and revertible, and that was what finally made a nervous team comfortable enough to go.
Done by Harshit Luthra, an independent infrastructure and AI engineering consultant. Bring me a similar problem →
Questions about this work
How do you migrate to Kubernetes with zero downtime?+
Run the old and new environments in parallel behind weighted ingress and shift traffic in small increments while watching error rates and latency. A bad signal means shifting weight back in seconds, not a panicked 2am rollback. The earlier failed attempts here flipped everything at once and hoped, which is what made them fail.
Why use GitOps for the migration?+
So every change is reviewable and revertible. With Argo CD the running cluster always matches git, and a deploy becomes a merge. That auditability is what finally made a team burned by past migrations comfortable enough to go.
What if something breaks mid-cutover?+
Every step was reversible by design. Because traffic shifted gradually behind weighted ingress, rolling back was turning the dial down, not an emergency. Nothing customer-facing went down across the whole cutover.