Confirm the release boundary
State what is being released, which users or markets are affected and which known issues remain. Link the release to accepted requirements and UAT evidence.
If the team cannot describe the production change and its user impact, the release decision is not ready. Revisit the earlier project readiness criteria before adding more launch controls.
Environments and production configuration
Confirm that development, test, staging and production responsibilities are understood. The environments do not need to be identical, but relevant differences must be known.
Review production domains, runtime configuration, feature flags, scheduled jobs, email providers, storage, CDN settings and third-party endpoints. Confirm that secrets are stored in the intended secret manager and that no test keys or accounts remain.
Authentication and permissions
Test sign-in, sign-out, account recovery, session expiry and any multi-factor or identity-provider flow in the production configuration.
Use representative roles to verify both allowed and denied actions. Include administration, support or back-office access, not only the primary user role. Confirm who can grant emergency access and how that action is recorded.
Integrations and API dependencies
List each production integration with its owner, credentials, endpoint, rate limits and expected failure behaviour. Test webhooks, retries, email or payment delivery and downstream updates where relevant.
Agree what happens if a dependency is slow or unavailable. A graceful degraded mode may make the issue a manageable risk; a silent data loss path is usually a blocker.
Migrations and production data
Define who runs each migration, the sequence, expected duration and validation method. Record backups or snapshots, freeze windows and the point of no return.
Rehearse complex or irreversible steps in a representative environment. Validate counts and critical records after migration instead of assuming a successful command means correct data.
UAT and known issues
Capture user acceptance against the release scope. Open defects should include severity, affected users, workaround, owner and target date.
Stakeholder sign-off means the impact is understood and accepted. It should not turn an undocumented issue into an invisible one.
Monitoring, logging and support
Confirm that the team can see application errors, failed jobs, integration failures and important business signals after launch. Logs must be accessible to the people on duty without exposing sensitive data.
Set alert thresholds and escalation contacts. Decide who watches the release window, who communicates status and when normal support ownership begins.
Deployment and rollback ownership
Document the release sequence, commands or pipeline, required approvals and the people authorised to deploy. Name one release decision owner.
Define rollback triggers and the recovery path for code, configuration and data. If rollback is not technically safe, document the forward-fix plan and the time needed to execute it.
Make the final call
Use three outcomes: ready, ready with accepted conditions or not ready. Every condition needs an owner and expiry date.
The main go-live checklist guide provides the shared launch foundation. For simpler public sites, use the website launch checklist instead.
Before the delivery team steps away, complete the software project handover checklist so access, documentation and operational ownership follow the release.