What is Zero-Downtime Cutover?

What is Zero-Downtime Cutover?

Zero-downtime cutover is a migration strategy where a production website or application transitions from one platform to another without any period of unavailability for end users. Unlike traditional "maintenance window" migrations—where you slap up a splash page and pray—zero-downtime cutover relies on traffic routing, reverse proxies, and incremental content sync to keep the old system serving requests until the new system is fully verified and ready. The approach became standard practice around 2018–2020 as CDN providers like Cloudflare and Fastly added programmable edge routing, making path-based traffic splitting trivial. We've shipped zero-downtime cutovers on 50+ CMS migration projects, moving sites from WordPress to headless setups on Sanity, Contentful, and Payload CMS. A typical use case: an e-commerce site doing 10K+ daily sessions that can't afford even 5 minutes of 503 errors during a Shopify-to-custom-Next.js replatform.

How it works

You run both old and new systems in parallel and shift traffic incrementally. Here's the sequence we follow:

1. Parallel deployment: The new platform goes live on a staging domain (e.g., new.example.com) with full production content synced via a migration script or webhook-based sync.

2. Reverse proxy / edge routing: A reverse proxy (we usually use Cloudflare Workers or Vercel Edge Middleware) sits in front of the production domain. It routes specific paths to the new system while everything else still hits the old one.

// Simplified Cloudflare Worker example
export default {
  async fetch(request) {
    const url = new URL(request.url);
    const newPaths = ['/blog', '/about', '/products'];
    const matchesNew = newPaths.some(p => url.pathname.startsWith(p));

    if (matchesNew) {
      return fetch(`https://new.example.com${url.pathname}${url.search}`, request);
    }
    return fetch(`https://old.example.com${url.pathname}${url.search}`, request);
  }
};

3. Incremental path migration: Move sections one at a time—/blog first, then /products, then the homepage. Each phase gets its own QA cycle.

4. Full cutover: Once every path routes to the new system and you've verified analytics, forms, and third-party integrations, update DNS to point directly at the new origin and remove the proxy layer.

5. Rollback plan: The old system stays warm for 48–72 hours. If something breaks, the proxy routes traffic back in under 60 seconds.

When to use it

Zero-downtime cutover makes sense when the cost of downtime is high—either in revenue, SEO equity, or user trust.

Use it when:

• Your site gets consistent organic traffic and you can't risk Google crawling a 503 during a maintenance window
• You're migrating a CMS but keeping the same domain (the most common scenario we see)
• The migration is complex enough that a single "big bang" deploy is risky—e.g., moving 10K+ pages with URL restructuring
• You need to A/B validate the new platform's performance (Core Web Vitals, conversion rates) against the old one before committing

Skip it when:

• The site is a small brochure site with <100 daily sessions—a 10-minute maintenance window at 3am is fine
• You're launching on a brand-new domain with no existing traffic
• Both old and new platforms use the same hosting and deployment pipeline (e.g., redeploying on the same Vercel project)

Zero-Downtime Cutover vs alternatives

A pure DNS cutover is often confused with zero-downtime cutover, but they're different. DNS propagation can take hours depending on TTL settings, and during that window some users hit the old system while others hit the new one. Zero-downtime cutover avoids this by keeping a single proxy in control of routing, so every user gets a consistent experience at all times.

Real-world example

We recently migrated a B2B SaaS marketing site (~3,200 pages) from a legacy WordPress multisite to Astro + Sanity CMS on Vercel. The site averaged 45K organic sessions/week and ranking loss wasn't an option. We set up a Cloudflare Worker as the traffic router, migrated content in 4 phases over 3 weeks, and monitored Lighthouse scores and Google Search Console indexing after each phase. The old WordPress instance stayed live the entire time. Total user-facing downtime: zero. Post-migration, LCP dropped from 3.1s to 1.4s, and organic traffic held steady through the transition—no indexing dip in GSC. The old server was decommissioned 5 days after the final cutover.