Scope acceptance
Are agreed capabilities, exclusions, and deferred items visible?
Customer and delivery owners accept the current launch scope.Evidence-backed launch gate
Make go-live decisions from current evidence
Review the gates that matter for this implementation, expose unresolved exceptions, assign conditions, and preserve the approver’s decision with the source records behind it.
A checklist is not complete because every row is green. It is complete when open exceptions are understood, owned, and reflected in the launch decision.
Free for up to five users. No credit card required.
Adapt fields, workflows, and dashboards without code. Explore 1,000+ app templates and use cases
- Use evidence and owners for each applicable gate
- Separate a condition from a passed requirement
- Carry open conditions into post-launch follow-up
Review the gates that can change the decision
Adapt the checklist to the implementation instead of forcing every customer through irrelevant questions.
Data readiness
Has the required data been loaded, reconciled, sampled, and accepted?
Open defects have explicit impact and disposition.Technical readiness
Are environments, integrations, access, monitoring, and support routes ready?
Failure and recovery paths have been tested where material.Training and operational readiness
Can the named users and support owners perform their first live tasks?
Attendance or capability evidence exists, with conditions for any gap.Blockers and risk
Are critical blockers closed and residual risks understood?
No hidden blocker contradicts the proposed decision.Support and ownership
Who owns launch day, early-life support, escalation, and customer communication?
Named owners and contact paths cover the launch window.Rollback and conditions
What triggers rollback or limits the launch?
Conditions are dated, owned, measurable, and visible after launch.Keep proposer, evidence, and approver responsibilities clear
The person preparing the review should not make missing evidence disappear.
Gate owner
Provides current evidence and an honest outcome for the gate.
Source link or attachment, review date, and named owner.Implementation manager
Builds the integrated recommendation and identifies dependencies between gates.
Proposed decision, open exceptions, conditions, and rollback plan.Launch approver
Records go, conditional go, stop, or return with comments.
Native review task and immutable decision history.Post-launch owner
Carries approved conditions and first-value follow-up after launch.
Open condition records remain visible until verified closed.Do not use “green” as a substitute for judgment
These decision labels tell the team what happens next.
All applicable gates passed and ownership is ready?
Self-hosted
Go — proceed on the planned date and start first-value follow-up.
Managed service
Record approver, decision time, evidence packet, and launch owner.
A known gap has a bounded, accepted mitigation?
Self-hosted
Conditional go — proceed within stated limits and track each condition.
Managed service
Record the condition, residual impact, owner, due date, and rollback trigger.
A critical gate failed or evidence is missing?
Self-hosted
No-go — stop the launch and execute the recovery plan.
Managed service
Record the failed gate, affected outcome, recovery owner, and next review date.
The review itself is incomplete or inconsistent?
Self-hosted
Return for correction — do not make a launch decision yet.
Managed service
Send precise reviewer comments back to the preparation owner.
Prepare asynchronously; use the meeting for decisions
A readiness meeting should not be the first time anyone sees a failed gate.
Collect current gate evidence
- Each gate owner updates outcome, evidence, exception, and recovery.
- Implementation manager resolves inconsistent states.
Publish the recommendation
- State go, conditional go, or no-go.
- List every open condition and rollback trigger.
Decide only unresolved material questions
- Open source records instead of reading copied summaries.
- Approver records decision and comments.
Execute and preserve conditions
- Start launch or recovery work.
- Keep open conditions in the portfolio until closure is verified.
Questions before the launch decision
What should be in a go-live readiness checklist?
Use applicable gates for scope, data, technical operation, training, support, security or compliance, open blockers, customer acceptance, communication, rollback, and post-launch ownership. Each gate needs evidence and an owner.
What is a conditional go-live?
It is approval to launch within explicit limits while one or more accepted conditions remain open. Each condition needs impact, mitigation, owner, due date, and rollback or escalation trigger.
Who should approve go-live?
Choose the person with authority over the combined customer, operational, technical, and risk decision. The approver may differ by implementation type, value, region, or risk.
Make the next launch decision from live gates, not a copied status deck
Open the conditional-go example and test whether the approver can see every condition, owner, due date, and source record needed to decide.