An Operational Readiness Checklist Before Platform Go-Live

Separate acceptance from operational readiness

Feature acceptance asks whether the system meets defined requirements. Operational readiness asks what happens during a busy period, a failed integration, an unavailable specialist, or a mistaken change. A successful test of one does not automatically answer the other.

AWS Well-Architected describes operational readiness reviews before launch and throughout a workload's life. The checklist below adapts that general discipline for an enterprise implementation handover. It is our editorial recommendation, not an AWS assessment or endorsement. AWS Well-Architected OPS07-BP02: Ensure a consistent review of operational readiness.

Ask for evidence in six areas

• Ownership: name the service owner, support contacts, escalation route, and who can authorize an urgent change.
• Monitoring: show which user-facing failures are detected, where alerts go, and how a responder distinguishes a real incident from noise.
• Recovery: demonstrate a relevant recovery procedure and record what was restored, what was not, and the conditions of the test.
• Change control: identify the exact release, configuration dependencies, rollback decision, and person authorized to stop the release.
• User support: confirm instructions, access arrangements, known limitations, and the route for reporting problems.
• Handover: give the operating team usable procedures and verify that they can carry them out without relying on the implementation team's memory.

Rehearse an ordinary failure

Hypothetical example: an external integration stops responding after launch. Ask the support team to walk through detection, impact assessment, escalation, and recovery using the proposed documentation. If the instructions depend on an absent consultant or an unknown credential owner, the handover is incomplete.

Keep the exercise proportionate to the service and avoid disruptive tests in production without authorization. Record the observed result rather than writing 'recovery tested' when the exercise covered only a discussion.

Make the release decision explicit

Use three outcomes: ready; ready with specific accepted limitations; or not ready. An accepted limitation needs an accountable owner, a stated consequence, and a follow-up action. Some issues should remain release blockers; a deadline does not turn missing recovery evidence into an acceptable risk.

After go-live, turn actual incidents and support questions into improvements to the readiness record. The goal is a service that can be operated consistently, not a checklist that is completed once and forgotten.

References & further reading

• AWS Well-Architected OPS07-BP02: Ensure a consistent review of operational readiness