Headless Replatform Cutover With Redirect and Analytics Gaps
A regional food bank is replatforming from a legacy monolith to a headless stack. The cutover is scheduled for Tuesday at 02:00, with DNS TTL already lowered to 300 seconds. The new site has 14,000 redirects generated from a crawl, but QA found 120 URLs that return 200 with the wrong page content, and 30 old campaign URLs are missing from the map. Analytics still reports only to the legacy property, and the SEO consultant is on leave. Rollback requires reverting DNS and restoring a database snapshot, roughly 40 minutes. The board's fundraising newsletter goes out Wednesday at 09:00 and links to three old campaign URLs. The executive director wants to proceed because the vendor's contract ends Friday; the engineering lead wants to postpone.
1. Make and justify a go/no-go recommendation for the Tuesday cutover.
Read the worked answer
Recommend no-go on Tuesday. The 120 URLs returning 200 with wrong content are more dangerous than 404s because they silently mislead users and search engines, and the 30 missing campaign URLs collide directly with Wednesday's newsletter. Analytics pointing only at the legacy property means the team cannot detect or prove impact during the most important fundraising week. The SEO consultant's absence removes a check, not a formality.
The vendor contract ending Friday is a commercial constraint, not a technical readiness criterion. Negotiate an extension or run the legacy site in parallel; a 40-minute rollback is acceptable but does not compensate for wrong-content pages. Offer a conditional go five days later: fix the 120 and 30 URLs, validate the full redirect map with a crawl diff, add analytics, and test rollback. If the executive director overrides, require written risk acceptance, a named incident commander, and a canary release. The reasoning is that cutover decisions should be based on reversible evidence, not deadline pressure.
2. Outline the cutover runbook and the rollback criteria you would require.
Read the worked answer
Pre-cutover: freeze content, snapshot the legacy database, verify DNS TTL, validate the redirect map against the old URL inventory, test analytics events, prepare synthetic checks for top journeys, and confirm on-call coverage. Cutover: release to a canary at 5% of traffic via weighted DNS or edge routing, watch error rates, redirect correctness, checkout and donation flows, and Core Web Vitals for 15 to 30 minutes, then ramp. Keep the legacy site running read-only.
Define rollback triggers in advance: 5xx above 1%, donation or form errors above baseline, redirect error rate above 0.5%, LCP above 4s, or confirmed wrong-content pages. Name the person who can call rollback and the communication channel. Post-cutover: monitor for 72 hours, crawl the site, review server-log 404s, check Search Console, verify newsletter URLs, and compare analytics against the legacy baseline. The reasoning is that a runbook converts a high-pressure decision into pre-agreed thresholds, which is especially important when the SEO specialist is unavailable.
3. What post-launch verification would you insist on to protect organic traffic and the fundraising campaign?
Read the worked answer
Before the newsletter, test the three campaign URLs and every URL in the email build, not just the home page. Submit the new sitemaps, verify the new property in Search Console, and compare coverage and canonical reports against the legacy baseline. Crawl the new site and diff the redirect map against the old inventory; review server logs for 404s and redirect chains. Check that analytics and donation events fire, and reconcile totals with the legacy property for at least a week.
Keep the legacy site accessible read-only for 30 days, and do not block staging or the old host in robots.txt before verification. Monitor rankings for the top 50 organic landing pages, and have a rollback path for any high-value URL that regresses. The reasoning is that cutover risk is concentrated in a small set of money pages and campaign links; broad checks are useful, but the verification plan must prioritize the URLs that fund the organization.