Low-risk cutover pattern for same-domain CMS migration — 2-week pre-flight, DNS TTL 300s, monitor 48h, keep WP firewalled 30 days

Standard low-risk cutover for a CMS-only migration on the same domain:

1. Build on staging.example.com with noindex enforced at the HTTP-header level (NOT just robots.txt — robots.txt does not stop indexing if pages are linked from elsewhere). Pair with IP allowlist + basic auth + framework preview-deployment password.

2. Two weeks before cutover: crawl staging with Screaming Frog, diff against production crawl, resolve every 404/3xx.

3. One week before cutover: lower DNS TTL on apex and www records to 300 seconds.

4. Cutover window (low-traffic time, never Friday):

   • Take a fresh DB snapshot of WordPress.
   • Swap the DNS A/CNAME record(s).
   • Watch traffic shift in Cloudflare/Vercel/Netlify analytics in real time.
   • Verify 50 random URLs return 200 on the new stack.
   • Verify 50 random old URLs that should be redirected actually redirect.

5. First 48 hours: monitor Google Search Console Coverage report. Set up host-platform alerts on 5xx and 4xx spikes.

6. Keep WordPress alive (firewalled, on a subdomain like wp.example.com accessible only by IP allowlist) for at least 30 days as the rollback target.

7. Rollback plan: DNS revert. With TTL at 300s, the world sees the old site within 5 minutes.

Cloudflare-in-front pattern for piecewise migration: put Cloudflare in front of both old and new origins; use Workers or Page Rules to route specific paths (/blog/* → new Astro origin, everything else → WordPress origin). Migrate path-by-path. Right pattern for large sites (200+ pages); only sane way to do a 1,000+ post blog without a multi-week dark period.