Zero-downtime website cutover: the checklist we use

The cutover is the part of a site relaunch everyone is nervous about, and the working estimate for the outage is usually somewhere between five and fifteen minutes. It does not need to be. The last one we ran, a national news site moving from a decade-old PHP application to a headless CMS on Kubernetes, was down for under thirty seconds. That number came from refusing to move DNS until the new site had proven itself, and from making the switch itself as small as possible. This is the checklist we used.

Before you schedule a date

1. Build the load test from real traffic. Sample a few thousand real requests from the current site's CDN logs so the test has the actual mix of pages, not the mix you imagine. Ours was 5,000 requests: articles 40 percent, market pages 18, tags 8, search 6, homepage 5.
2. Run the test from somewhere that can generate the load. A shared NAT gateway's connection-tracking ceiling capped our first attempts. Dedicated nodes on public subnets fixed it.
3. Test at multiples of the real peak, not at the real peak. A capacity ramp at 1, 1.4, 1.9, and 2.4 times the known peak tells you where the ceiling is. Ours never reached it: at 1,000 requests a second, 2.4 times the real email-blast peak, availability was 100 percent, p99 was 61 milliseconds, and the origin was using 11 of 20 possible pods.
4. Deploy under load. Run the realistic mix at twice peak for twenty minutes and trigger a rolling restart of every origin pod in the middle of it. If the deploy registers as anything at all, fix that before launch day, because you will need to deploy on launch day.

Fix what the test finds

The load test is the point; the fixes it produces are the outcome. Ours found four things worth knowing about in advance.

• About 80 percent of a cold stampede was HEAD requests from email link scanners that the application rendered as full pages. Short-circuiting them at the web server took cold-cache p99 from 17.5 seconds to 53 milliseconds.
• Cacheable anonymous responses were setting a session cookie, so cookie-carrying traffic bypassed the edge. Stripping it lifted cache offload from 70 percent to the high nineties under test.
• Autoscaling on CPU alone lags a traffic spike. Request-rate autoscaling alongside CPU catches it.
• A readiness probe that fails under transient saturation lets a spike take healthy pods out of rotation. Make it tolerant.

Canary on real traffic

Weighted routing at the CDN with session stickiness, at 1 percent, then 5, then 15 percent of real production traffic, with rollback being a single DNS re-association. Each step gets a day or more. This is where you find the redirect rules, the analytics tags, and the ad slots that no test suite covers.

The morning of the switch

1. Profile the current site's real requests one more time. We pulled 18,000 real legacy requests that morning and found that a third of the top 250 paths by weight would return 404 on the new site, mostly RSS feed variants and trailing-slash differences. Those decisions were made before the switch instead of discovered after.
2. Measure propagation for every configuration change on the critical path. CDN configuration propagation measured at 167 seconds. Anything that takes minutes moves off the critical path and gets done in advance.
3. Check that the change targets the right thing. The planned promotion pointed at the wrong CDN distribution, which would have left production configuration outside infrastructure as code permanently. A dry run caught it.
4. Write down the rollback and confirm it is one step. If rollback is more than one action, it is not a rollback plan.

The switch

Do it on a quiet morning. Ours was a Saturday. With the slow changes already propagated, the switch itself is the DNS or CDN origin change, and verification of every key path within minutes: homepage, top articles, feeds, search, sign-in, checkout if there is one, and every legacy passthrough that still points at the old system.

Day one will still have incidents

The difference is whether the platform handles them or people do. On our day one, a scanner crawled a listing to page 69 and was stopped by the rate-limit rule. A pod-flapping bug caused by the vertical autoscaler rewriting CPU requests under the horizontal one was root-caused and fixed by policy the same afternoon. Out-of-range listing pages got edge-cached 404s in a patch release shipped the same day. None of it reached users.

An honest number about caching

The 97 percent cache-hit rate from the synthetic test was an artifact of its 350-URL list. Real traffic settled around 52 percent, the same as the legacy site on the same readers. If your capacity plan depends on a cache-hit rate you measured in a load test, redo the plan with the origin doing most of the work.

The full story

The harness, the canary, and the launch-day findings are in the headless CMS migration case study.

Relaunching a high-traffic site?

We'll build the load test from your real traffic and tell you whether the new stack is ready before you move DNS.

Schedule a call