The Deploy button is green. The project manager announces go-live at 2 p.m. At 2:20, the site responds — but transactional email still leaves the old server, the certificate covers the wrong domain, and support was not warned about a new ticket flow. At 6 p.m., leadership asks for rollback nobody can execute in under two hours.
Going to production is an organizational event, not a code push. This checklist links what tech executes and what the business must understand — without useless jargon, without forgetting what hurts (DNS, MX, cookies, billing).
Before D-day: business alignment
A thirty-minute meeting is enough if it produces a shared one-page document. Each line needs a written answer: maintenance window (date, time, timezone, who stays available four hours), three measurable success criteria (login OK, test payment OK, server error rate below one percent), rollback decider and procedure, comms plan (client email, status page, support brief), and data constraints (database migration, write freeze).
If the business cannot explain rollback in one sentence, you are not ready.
This document is not bureaucracy: it prevents a director announcing "everything is live" while confirmation emails still do not send.
Technical checklist: infrastructure and DNS
On infrastructure, verify a recent production backup exists and restore was tested within seven days. Production must match staging (PHP versions, extensions, cron). Production secrets must be distinct — never copied from a dev file. Monitoring must alert on server errors, disk space, and certificate expiry. Logs must be centralized or accessible without searching three servers.
On DNS and certificates, lower TTL 24–48 hours before cutover. Document A, AAAA, and CNAME records with a rollback plan to the old IP. If email moves servers, verify MX, SPF, DKIM, and DMARC. TLS certificate must cover all hostnames (www and apex).
On application, apply database migrations with a rollback script on failure. Clear or warm cache per strategy. Use feature flags for gradual enable. Expose a health check endpoint (/health) for the load balancer.
D-day: sequence and roles
Sixty minutes before cutover: content freeze, final backup, on-call confirmed. At H-hour: DNS or traffic switch; watch propagation with external tools, not just from your office. Fifteen minutes after: automated smoke tests and manual business path (order, signup). One hour after: metrics review and continue/rollback decision. Twenty-four hours after: raise DNS TTL and hold a short post-mortem even on success.
Name roles: incident commander (rollback decision), tech lead, comms, business validator. Without names, everyone waits for someone else to decide.
What non-tech should hear
Explain without condescension: "We change where the site lives on the Internet — not just the design." "DNS propagation can take up to X hours despite low TTL." "Rollback brings the old site, not an intermediate version." "First hour = enhanced monitoring, not guaranteed outage."
These sentences prevent misunderstandings like "the site is live so everything works" while payment or email paths remain broken.
The peak: successful go-live = nobody notices — failed go-live = everyone
Marketing counts confetti. Ops counts full paths: signup, payment, email, admin, partner API.
Decide and move forward without blind spots
Write a one-page business document and a tech checklist signed by the team. Time rollback on staging — if it takes over an hour, fix before D-day. Brief support with likely incidents and standard responses. Prepare a comms plan if degradation exceeds thirty minutes. Hold a 48-hour post-mortem: three keep, three improve.
See blue-green deployment and application health check. Compare hosts via the directory.
Frequently asked questions
What is the difference between staging and production?
Production serves real users with availability commitment, tested backups, alerting monitoring, and documented rollback. Staging mirrors configuration — not always real load or properly anonymized data.
How long before go-live should you lower DNS TTL?
24–48 hours before cutover, set TTL to 300 seconds. Raise it after stabilization to reduce load on DNS servers.
What must a non-technical project manager understand?
Maintenance window, residual risk, rollback decider, incident comms channel, and measurable success criteria — not just "looks ok."
Do you need a written rollback runbook?
Yes — numbered steps, named owners, estimated duration, tested at least once on staging. Improvised rollback costs more than the initial incident.
Production starts when the full client journey holds — not when the CI pipeline shows green.