Zero-downtime launches

The worked example: this very site

In September 2026 this site moved host and DNS, live, mid-week, with zero downtime. The sequence ran exactly as this page describes: the new host was deployed and verified on a temporary address first (all 565 pages, assets, certificates), DNS records were swapped at the registrar with low TTLs, and during propagation both stacks served working content, visitors never saw a gap. The old host stayed warm for the cutover window, then was retired. No screenshotted disaster, no apology post, because the launch was rehearsed before it was real. That is the standard, and it applies to every launch here, from a five-page brochure to a store with checkout flowing.

The checklist that makes launches boring

• Rehearsal on staging: the full QA pass runs on the final build, not a skim, the whole checklist
• Cutover at the quiet hour: your analytics say when traffic is lowest; that is when DNS swaps, deploys land, or versions flip
• Rollback staged before launch: the old stack stays deployable until the new one proves itself, rollback is a decision, not a rebuild under panic
• Redirects mapped: every old URL lands somewhere intentional, the migration discipline that preserves rankings
• Verification battery: forms, checkout, key pages, certificates, analytics, exercised on production immediately after cutover
• Monitoring live from minute one: uptime checks and error tracking watch the new stack while humans sleep (see uptime & monitoring)

Why launches fail, when they fail

Launch-day failures are almost never the code, the code was tested. They are the untried things: a DNS record typed wrong at midnight, a cache layer nobody flushed, a payment webhook pointing at staging, an email service that was never connected on the new host. Every item on those lists is preventable by the boring rule: nothing happens on launch day for the first time. Every step gets rehearsed on staging, every external service gets connected and tested in advance, every credential is verified before the cutover window opens. The disasters you have heard about were launches where launch day was rehearsal day.

What this means for your project

Your launch gets a written runbook: the checklist, the cutover window, the rollback path, the verification battery, and who does what. You approve it before launch week. If the plan cannot make the launch boring, the launch is not ready, and the honest move is to hold, not to hope. The staging discipline makes that a non-event, the monitoring catches what slips, and the working method ties it together. Launches here are rehearsed, scheduled, and dull, exactly as they should be.