The relaunch everyone remembers
You remember the day more clearly than the months of work before it. The site went dark some time in the morning. Someone blamed the domain, someone else the certificate, and for hours nobody could say which. When pages came back, the old links did not: product pages bookmarked, linked from partner sites and printed on packaging now returned an error. Search traffic fell the following week and took a quarter to recover, and you were the one explaining it upwards, more than once.
None of that was decided on the day. The domain, the certificate and the redirect map only surfaced that morning; all three were settled, or left unsettled, in the weeks before it.
Why launch day is the wrong unit
A relaunch that goes wrong was almost always planned as an event: a date, a build that has to be ready for it, and a morning when the switch is thrown. Everything that can fail is compressed into that morning, precisely when the people who could fix it are least able to think.
A cutover planned as a sequence looks different. Each stage has a named owner, a verification step that must pass, and a written statement of what happens if it does not. Launch day becomes one stage among several, and a short one.
The question stops being whether the site will be ready on the date and becomes three: what has to be true before traffic moves, who checks it, and what you do if it is not true. If your supplier cannot answer all three in writing, you have a date, not a launch plan.
The four stages
Preparation. Domain records are prepared and time to live values on the existing ones lowered days ahead, so that propagation takes minutes rather than most of a day, and reversing it takes the same. Certificates are issued and tested before the new stack is public. If someone else in the group manages your domain, this stage starts weeks earlier.
Verification. Content is frozen. If marketing cannot freeze because a campaign is running, the freeze window becomes the constraint the date is planned around, rather than something agreed verbally and broken within the hour. The new stack is then verified against the frozen state: redirects, forms, tracking, and every domain that resolves to it. On a launch we delivered for a German medical device manufacturer, a second brand domain was served from the same application through request time routing. Another system went live in the same window, so the sequence had to account for a dependency outside the website.
Switch. Records are activated, propagation is confirmed from inside and outside the office, and a test enquiry arrives. Each step passes or triggers the rollback; nothing gets debugged live.
Observation. A defined window with a named person watching error rates, request counts and the redirect log. It passes when the error rate stays inside the agreed band throughout; unmapped old URLs go into the map the same day.
Redirects from behaviour, not structure
Most redirect maps are built from the new sitemap. Someone lists the new pages and decides which old page each replaces. That covers the pages you remember. It misses the ones you do not: the PDF linked from a trade publication four years ago, the campaign page a distributor still links to, the product URL on every printed brochure still in circulation.
Those requests exist in data you already hold. Access logs from the current host show every URL requested in the last year, including the ones that already fail. Your analytics landing page report shows where people arrive. The search engine's own reporting shows which URLs it has indexed and still crawls. Combine the three, sort by request count, and map from the top down. The tail is longer than anyone remembers publishing, and it is where the traffic from your last relaunch went.
The rollback position
Under pressure, the only direction available is usually forward, because nobody wrote down the alternative. A rollback position is that alternative, defined before the switch: what state you return to, how long the return takes, what triggers it, and who is allowed to call it.
The trigger should be specific. Not "if something goes wrong" but "if a test enquiry has not arrived within 20 minutes of the switch". The caller is one named person with the authority to decide without a meeting.
Lowered time to live values make the return path minutes rather than days. Keeping the old stack running and reachable through the observation window means there is something to return to. Both belong in the written plan, next to the stages and their owners, and that plan is a document you hold rather than one your supplier keeps. If your agency says it will be fine, ask for the rollback trigger in writing. If none exists, that is the answer.
What a quiet launch feels like
It feels like nothing. Traffic moves mid-morning. The switch owner confirms it. The person in the observation window watches for the agreed period and reports that nothing needs attention. Sales receives the same enquiries as the week before. Leadership does not hear about it, because there is nothing to hear.
That outcome is a planning result, not a technical one. The checklist below is built from the written one we used on the launch described earlier, which had a named owner and a verification step for every row. The rollback trigger is the column you agree before your own switch. Run it against your own plan, or your supplier's, and see which rows come back empty.
