What to have ready before launch day starts
Launch day should be an assembly job, not a scavenger hunt. Every item below has to be in your hands before the window opens: the access, the finished content, three decisions that cannot survive being made under time pressure, and a named person with authority to stop the work. If one of them is missing, move the date. Postponing costs a day. Starting anyway costs you a domain answering with neither the old site nor the new one while you chase a password, and that half-state is what visitors, resolvers and crawlers record.
The go/no-go table
Fill this in the day before. A blank cell is a reason to reschedule, not a task for the morning.
| What you need in hand | Ready means | If it is missing mid-launch |
|---|---|---|
| Hosting account access | You opened it yourself within the last day | The reset mail goes to an address nobody still reads |
| Registrar and DNS access | Logged in, edit screen reachable, lock status known | The one action that makes the launch real is the one you cannot perform |
| Access to the site being replaced | Files, database and its DNS all reachable | No rollback. Only forward |
| Final content | Signed off in writing on the exact build | Edits arrive after the first crawl, not before |
| Address assignment | Written map of property to account and address | Placement gets improvised, and separation quietly collapses |
| Certificate approach | Names and timing already chosen | Warning screens on a live domain |
| Email decision | Recorded before anyone edits a zone | Mail stops, and nobody notices for hours |
| Approver | Named, reachable, empowered to halt | The launch waits on a phone that is not answered |
Access you hold, not access you believe exists
"Somebody on the team has it" is not possession. Open each of these yourself and confirm it lets you in:
- The hosting control panel, plus the billing login if they differ
- The registrar account holding the domain, and the DNS editor if it sits elsewhere
- The current host and current CMS, if you are replacing something live
- Ownership of the analytics and search console properties, not view rights
- The repository or archive holding the authoritative copy of the build
- Any keys the pages need to render: payment, maps, embedded services
Recovery routes matter as much as passwords. If registrar two-factor sits on a departed contractor's device, you do not have registrar access, whatever the password manager says.
Content that is finished, not nearly finished
Signed off means a specific person approved a specific build in writing, and the build is frozen. Beyond the copy, three things get discovered missing at the worst hour: a working contact route, whatever legal pages your market requires, and the complete old-to-new URL map when a site is being replaced. That map is a content decision, not a technical one. Every old address carrying value needs a chosen destination, and choosing forty of them at speed produces forty guesses.
Three decisions that cannot wait for the day
- Address assignment. Which property sits on which account and which address, written down. The reasoning behind the map belongs to network planning; on launch day you follow it, you do not derive it.
- Certificates. Decide which hostnames are covered, whether both the bare domain and the www form must answer, and whether issuance happens before the cutover or after. Choose the type in advance too, since validated products are not instant. See certificate options.
- Email. The sharpest of the three, because mail and web share one name. Decide whether mail moves with the site, stays exactly where it is, or does not exist yet for this domain. If it stays, the records carrying it are the ones nobody touches, and that instruction belongs in writing before the zone is opened.
Someone has to be able to say stop
Name one approver reachable throughout the window who is allowed to halt the launch, plus a second name for when the first is unreachable. Agree the rollback trigger beforehand, in plain terms: which condition means revert rather than push through. Deciding that while a live domain misbehaves is how teams talk themselves into continuing.
When every row above is filled, the sequence itself is straightforward, and the other launch playbooks cover the order you run it in.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.