Website Launch Template
A narrow, time-boxed checklist for the launch event itself: DNS cutover, redirects, tracking verification, and a rollback plan. Not the whole build behind it.
Every check has an owner and a timestamp. Launch day isn't the time to improvise who's watching what.
Why launch day goes wrong even after a good build
A website can be well built and still have a bad launch, because launch day has its own failure modes that have nothing to do with the pages themselves. A build project ends when the pages are finished; a launch is a single event with its own sequence, its own narrow time window, and its own way of going wrong regardless of how solid the build was.
Redirects get written the day of, not before. Old URLs that used to rank go to a 404 instead of their new equivalent, and that's a loss that shows up in traffic for months, not an inconvenience that gets fixed same-day. Search engines don't re-crawl and recover that ranking on request.
Tracking breaks silently. Analytics and conversion tags get swapped along with everything else, nobody re-verifies them post-cutover, and the team finds out three weeks later that two weeks of traffic data don't exist, right when someone wants to report on how the new site is performing.
There's no rollback plan because launch is assumed to go fine. DNS propagation, a broken checkout, a certificate that didn't renew: any of these needs a fast, pre-decided path back, not a debate happening while the site is down and customers are watching it happen. Writing the rollback plan into the card as a required field before cutover, the way this template does, is what turns that debate into a lookup instead.
Ownership of each check is assumed rather than assigned. Everyone thinks someone else is watching the SSL certificate or the contact form, and it turns out nobody actually confirmed either one, because "the team" isn't a person who can be held to a checklist.
The structure, and why each part is there
Everything that must be true before cutover starts: redirect map finalized, tracking codes verified in staging, stakeholders notified of the launch window. Nothing in this column is optional preparation. It's a gate the launch shouldn't clear without.
The narrow, time-boxed act of pointing the domain at the new site, separate from everything before and after it, because it's the step with the tightest margin for error.
SSL, forms, tracking, redirects: each check assigned to a specific person with a timestamp when it's confirmed, so "someone checked that" has a name attached.
The old DNS record, the previous deploy, and who has authority to revert: recorded before cutover starts, not improvised if it goes wrong, with a clear owner who can make the call without waiting for a meeting.
The built-in wiki holds the go/no-go call and who made it, with page history, so a rushed decision on launch day is still reconstructable afterward.
If a check fails mid-launch, one tap raises it with context attached, so the right person is pulled in immediately instead of it sitting in a chat thread while the clock runs.
The 24–48 hours after cutover, treated as their own tracked stage: traffic, error rates, and form submissions checked deliberately rather than assumed fine because nobody's complained yet.
How to use it
- 01Build the redirect map at least a week out, not the morning of. Every old URL that ranks needs a destination before it stops resolving, and mapping a full site takes longer than it looks.
- 02Lower the DNS TTL 24–48 hours before cutover. A high TTL turns a five-minute rollback into a half-day wait if something goes wrong, which defeats the purpose of having a rollback plan at all.
- 03Assign every go-live check to one named person, not to "the team." Shared ownership on launch day means nobody actually checks. Pick one name per check and put it on the card.
- 04Write the rollback plan before the pre-launch column is marked complete. It shouldn't be possible to reach cutover without one, however confident the team is about the deploy.
- 05Re-verify tracking after cutover, not just before it. A tag that worked in staging can still fail to fire on the live domain.
- 06Keep watching for the first 24–48 hours, not just through the moment of cutover. Most launch problems surface within a day, not within the first ten minutes.
Launch day works best as a short, standalone project rather than a task tacked onto the end of the build board. A separate card structure means the checklist can be reused unchanged for the next launch, redesign, or domain migration, without digging through a finished build project to find it.
It's also worth deciding the go/no-go criteria before launch day starts, not during it. Write down what would actually stop the launch (a failed migration dry run, an unresolved sev-1 in the build) so the decision on the day is a lookup against a written standard rather than a judgment call made under pressure with everyone watching the clock.
- Finish the redirect map days before launch, not the morning of
- Write the rollback plan before cutover, so it's a decision and not an improvisation
- Re-check tracking after cutover: a tag working in staging isn't proof it fires live
Common questions
That template covers the whole build (discovery, design, build, QA) over weeks or months. This one covers only the launch event itself: the checklist for the day the site actually goes live, and the day or two around it. Most teams use the build template first and switch to this one in the final week, once the site is essentially finished and the remaining risk is entirely in the cutover.
Move the card back to pre-launch and log the reason on the wiki page. Postponing is a normal outcome of a go/no-go check, not a failure of the checklist. Nothing about the board assumes the first attempt succeeds.
Yes. All templates are included on the Free plan, which covers up to five users and two projects and doesn't expire. See pricing for what changes on paid plans.
It's built around a domain and DNS cutover specifically, so it's a closer fit for a website or web app launch. The column structure (pre-launch checks, cutover, go-live verification, rollback plan) can be adapted, but the specific checks would need reworking for a different kind of release.
Whoever owns a go-live check, plus whoever has authority to call go/no-go or trigger the rollback. Keeping the list short on launch day means fewer people are guessing at status and more are actually watching their assigned check.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required