Zero-Downtime Deployments: Blue-Green, Canary and Rolling Releases Explained

A maintenance window was an acceptable customer experience when SaaS meant enterprise software used during business hours in one region. A product with customers across time zones does not have an off-peak window, which makes zero-downtime deployment a requirement, not an optimization — the only question is which strategy fits the team's risk tolerance and infrastructure.

The three strategies, compared honestly

• Rolling deployment — replace instances gradually behind a load balancer; simplest to set up, but two versions of the code run simultaneously during the rollout, which every change must tolerate.
• Blue-green deployment — a full second environment is stood up, tested, and traffic cut over all at once; instant rollback by cutting back, at the cost of running double infrastructure during the switch.
• Canary deployment — the new version serves a small percentage of real traffic first, monitored closely, before a gradual full rollout; the safest for catching a bad release early, and the most operationally complex to automate well.

We default clients toward canary for anything with real production risk (payments, core workflows) and rolling deployment for lower-stakes services, reserving blue-green mainly for database migrations or infrastructure changes too large to canary safely.

The step teams skip: backward-compatible database migrations

None of these strategies protect you if a deploy includes a database migration that the previous code version cannot tolerate running alongside. Every zero-downtime deployment strategy requires migrations designed to be backward compatible for the duration of the rollout — additive changes first, destructive changes only after the old code path is fully retired. Skipping this is the most common cause of a "zero-downtime" deploy that was not.