Go-live readiness is the state where a launch can run in production without creating avoidable security, compliance or operational risk, and where the people who will run it can do the work on day one. Most checklists cover the first half well. The second half is where launches stall. Before you build another training course for go-live, decide what capability the work will actually demand, and gather the proof that your teams can perform it.
This guide covers what a readiness review should include, how to run a rehearsal, how to structure a go/no-go decision, and how to plan the weeks after launch.
TL;DR
- Go-live readiness covers four areas: people, process, technology and support. A launch that is technically ready but operationally unprepared is not ready.
- Training sign-in sheets show attendance. Readiness needs observation of people doing the real work, ideally in a rehearsal.
- Every readiness activity needs one named owner, a target date and a verification method.
- A go/no-go decision needs criteria agreed in advance, a named decision owner and a rollback plan.
- Plan stabilization before launch: set exit criteria for the support period while the project team is still fully engaged.
Table of Contents
- What go-live readiness actually means
- The four areas a readiness checklist should cover
- Why training completion is a weak readiness signal
- Before you build that course: diagnose first
- Running a go-live rehearsal
- Make every readiness item owned and verifiable
- The go/no-go decision
- Plan stabilization before you launch
- Perspective: readiness is a capability question, not a calendar question
- How Cognistry supports go-live readiness
- A readiness review you can run this week
- FAQ
- Sources
What go-live readiness actually means
A glossary definition from a security and governance publisher describes go-live readiness as being prepared to operate in production without avoidable security, compliance or operational risk. It depends on tested controls, approved access, documented processes and a clear remediation plan for anything that could block audit approval or business continuity.
The Washington State technology agency’s project management best practices summary frames it as a proactive process that sets clear, measurable criteria for a successful deployment. The same document says readiness planning typically begins in earnest three to four months before deployment.
Two ideas in those definitions matter most.
Measurable criteria. “We feel ready” is not a criterion. A criterion can be checked, by someone, on a date.
Operating, not just launching. The system switching on is an event. Readiness is about what happens at 9 a.m. on the first Monday, when a customer calls, an order fails or an approval lands in the wrong queue.
The four areas a readiness checklist should cover
A go-live readiness checklist should cover people, process, technology and support. Teams usually get the technology column right because it has tooling, test scripts and engineers who care. The other three columns tend to be thinner.
Technology
This is the familiar ground: configuration, data migration, interfaces, performance, backups and security. The Washington State summary lists criteria such as an approved security design review and confirmed directory-based access in every environment, production included. The federal healthcare research agency’s EHR go-live planning checklist adds verified user access and privileges, tested reports and interfaces, backups and downtime procedures.
Process
Can the new way of working actually be run end to end? Documented procedures, handoffs between teams, approval paths and exception handling all belong here. Ask where the old process quietly depended on a workaround, a spreadsheet or one person’s memory. Those dependencies do not migrate on their own.
Support
The same AHRQ checklist calls for escalation procedures and defined roles for the support team. Who answers the first question on launch day? Who decides when a problem is a defect and when it is a training gap? If the answer is “the project team,” you have a stabilization problem waiting to happen.
People
This is the column that most often gets reduced to a training completion rate. Completion tells you who sat through the material. It does not tell you whether a claims processor can handle an unusual case in the new system, or whether a supervisor knows when to escalate.
Why training completion is a weak readiness signal
The AHRQ checklist makes a useful distinction. It lists training sign-in verification and policy sign-off, and it lists something separate: a staff system walk-through of a patient visit from beginning to end. Attendance and sign-off are one kind of check. Walking the real workflow is another.
The CDC’s infection-control assessment guide draws the same line in a different field. It defines competency-based assessment as verifying competency through knowledge-based testing and direct observation. Testing covers what someone knows. Observation covers what they do. The CDC’s guidance on evaluating training also recommends assessing learning transfer and building assessments, such as observations, into the training itself.
A CDC-hosted paper on entrustable professional activities goes further. It treats readiness as a judgment about whether someone can perform an integrated task at an appropriate level of supervision, using methods such as direct observation, checklists and simulation. That is a useful way to think about launch day: not “do they know the system,” but “can this team run the work, and how much help will they need?”
For a go-live, this means adding a workforce section to your checklist that asks different questions:
- Which decisions will people make differently in the new environment?
- Which of those decisions carry the highest cost if they go wrong?
- Have we watched people make them, in a realistic setting, before launch?
- Where people struggled in practice, was the cause a gap in the person or a gap in the environment: unclear process, missing tool access, a confusing screen?
That last question changes what you do next. If the environment is the cause, more training will not fix it. A process change, an interface fix or a clearer escalation path will.
Before you build that course: diagnose first
When readiness looks shaky, the reflex is to commission training. Sometimes that is right. Often it is not.
Before you build, work through a short diagnosis:
- What does the work require on day one? Name the specific judgments and actions, not the topics.
- Where does your own material say people struggle? Quality findings, frontline friction, support tickets from earlier releases, and what your subject-matter experts say they correct most often.
- Is the gap about capability at all? Missing access, unclear ownership and conflicting incentives all produce errors that look like training problems.
- If learning is the right enablement play, what should people practice? Build for the decisions identified in step 1, not for a tour of features.
This is the order we work in at Cognistry, and it saves launches from a familiar failure: a polished course library, a high completion rate and a floor of people who still do not know what to do when the screen shows something unexpected. Our piece on AI workforce readiness makes the same argument for tool rollouts: buying or deploying a tool is not the same as being ready to use it well.
Running a go-live rehearsal
A rehearsal is where the checklist meets reality. One practitioner toolkit describes a go-live rehearsal as a full mock cutover run at the real times, after which the team updates the runbook with actual durations and tests reconciliations and smoke tests. That covers the technical rehearsal well.
A readiness rehearsal should also include the operating teams. Here is a practical structure.
Rehearse the cutover
Run the full sequence at the times it will happen. Record how long each step actually takes, who was needed and which handoffs stalled. Update the runbook with real durations, not planned ones.
Rehearse the work
After the technical steps, put representative staff through realistic scenarios in the new environment. The AHRQ checklist’s end-to-end walk-through is the model: take a complete unit of work from start to finish. For a service desk, that is a ticket from intake to resolution. For finance, a period close step. For a clinic, a patient visit.
Include the awkward cases:
- A request that does not fit the standard path
- A system error with a customer waiting
- A handoff to another team that has not acted yet
- A decision that needs an approval someone else holds
Observe and record
Assign observers who know the work. Note where people hesitated, where they asked for help, where they chose wrongly and where the environment misled them. AHRQ’s lessons from bar-coded medication administration rollouts point to experiential learning or practicum and visible super-users with demonstrated peer-support ability as important preparation. Rehearsals are where you find out who those people are and whether there are enough of them.
Close the loop
Sort what you saw into three buckets: fix the environment, adjust the process, or build practice for a specific judgment. Then rehearse again. A rehearsal that finds nothing was probably too easy.
Our Sim product exists for the third bucket: practice environments where people work through realistic decisions before the stakes are real.
Make every readiness item owned and verifiable
The most useful rule in any readiness plan is also the simplest. Every readiness activity needs one named owner, a target date and a verification method. Not a team, not “TBD,” not “ongoing.”
Here is how that looks for the workforce column.
| Readiness item | Owner | Verification method |
|---|---|---|
| Frontline team can complete the top-risk scenarios in the new environment | Operations manager | Observed rehearsal with scenario results recorded |
| Escalation path is understood and works | Support lead | Test escalations during rehearsal, response times logged |
| Super-users are in place for each shift and site | Change lead | Named list, coverage schedule, observed peer support |
| Process documents match the new workflow | Process owner | Walk-through by someone who did not write them |
| Policy sign-offs complete | Department head | Sign-off record |
Notice that sign-off is one row among five. It belongs on the list, but not as the whole list.
The go/no-go decision
The go/no-go meeting should be short because the preparation behind it is thorough. The U.S. General Services Administration’s M3 Playbook describes a go/no-go package that includes a scorecard, a risk register, a defect summary, outstanding items with dates, a recommendation and pre-agreed no-go conditions. It also says rollback authority should be named in advance.
Define criteria before the pressure arrives
The playbook says go/no-go criteria should be defined upfront, with contingency plans for no-go or rollback scenarios. Those plans cover communications, activities, affected systems and interfaces, and roles for re-planning and managing legacy systems.
Agree the criteria when nobody is yet tired, behind schedule or defending a date. A criterion set in week two is a standard. A criterion negotiated on launch eve is a bargain.
Add workforce criteria that mean something
A go/no-go scorecard often has rows for defects and interfaces, and a single row for “training complete: 96%.” Replace that with criteria such as:
- Top-risk scenarios performed correctly in rehearsal by representative staff from every affected team
- Super-users named and available for every shift in the first weeks
- Escalation path tested, with owners confirmed
- Known environment gaps (access, screens, handoffs) fixed or covered by an agreed workaround
Name who decides
One ITIL-focused practitioner article puts it bluntly: if it is unclear who owns the go-live call, who carries the risk and who is accountable if it fails, the service is not ready, regardless of delivery pressure. The toolkit cited earlier recommends a named cutover manager with the authority to invoke contingencies, halt steps or call no-go when defined triggers are met.
Handle gaps honestly
If a criterion is not yet met, the Washington State summary says the readiness briefing should explain the gap and outline specific actions to be ready by the go/no-go decision. That is a better position than hiding the gap. It turns a surprise into a plan.
Plan stabilization before you launch
Go-live is the start of a new phase. The practitioner toolkit suggests planning hypercare as a 30 to 90 day window that carries the team through at least one full close, with exit criteria defined before go-live. The operational readiness guide adds sensible exit criteria: normalized incident volumes, evidenced user confidence, and support without project-team involvement.
Treat what happens in this window as input, not just firefighting. Patterns in support requests show you where the workflow, the environment or people’s practice needs work. A good readiness review asks questions twice: once for go-live, and again for three months to a year out, so both scenarios are prepared for.
Perspective: readiness is a capability question, not a calendar question
We see the same pattern across enterprise launches. The technical workstream has a plan, a test log and a clear owner. The workforce workstream has a training schedule. Then launch day arrives, and the gap between knowing the system and running the work shows up as errors, escalations and a quiet loss of confidence.
Our view is that readiness should start with a diagnosis. What does the work require? Which decisions carry the most risk? What does your own material, from strategy documents to frontline friction to quality findings to what your experts correct every day, say about where people will struggle? Only then does it make sense to decide whether learning is the right enablement play at all, and what people need to practice.
That is why we built Cognistry to start before the build. Diagnosis comes first, the response is grounded in your organization’s own source material, and practice is designed around operational judgment rather than recall. Data drag, the gap between what people learned and what they do, is cheaper to close before go-live than after.
Show us a launch with a completion rate and no observed rehearsal, and we will show you a go/no-go meeting running on confidence. Confidence is not a substitute for evidence.
Brian
How Cognistry supports go-live readiness
If you are preparing a launch and want to know what capability the work will demand, Cognistry Platform is where that starts. We help teams diagnose what capability the work requires, decide whether learning is the right response, and ground the design in their own strategy, frontline friction, quality findings and expert knowledge. From there we structure practice, including decision environments and simulations, so people work through realistic situations before they face them live.
If your launch involves product and delivery teams, see how we work with product and delivery teams. For frontline process changes, our operations teams page shows the approach. Ready to see how it would apply to your go-live? Start at the Cognistry Platform page and request a demo.
A readiness review you can run this week
You do not need a new program to improve your next go-live review. Use this sequence:
- Add “people” and “support” columns to your checklist if they are not there.
- Give every item an owner, a date and a verification method.
- List the five to ten highest-risk work scenarios under the new setup. Pick them with the people who do the work.
- Schedule a rehearsal that runs those scenarios with representative staff and observers.
- Sort findings into environment fixes, process fixes and practice needs.
- Write go/no-go criteria, with named decision rights and a rollback plan, before the final weeks.
- Set hypercare exit criteria now.
The point of the exercise is simple. Replace “we think we are ready” with something you can show.
FAQ
What does go-live readiness mean?
It means a system, service or process is prepared to operate in production without avoidable security, compliance or operational risk. In practice that spans technology, process, support and people. Readiness is shown by criteria that someone has checked, not by a team’s sense of confidence.
What should a go-live readiness checklist include?
It should cover people, process, technology and support. Typical items include tested access and interfaces, documented procedures, escalation paths, backups and downtime procedures, named support roles and observed workforce performance. Each item needs an owner, a target date and a verification method.
What is a go/no-go checklist?
It is the decision package reviewed before launch. Public-sector guidance describes a scorecard, risk register, defect summary, outstanding items with dates, a recommendation and pre-agreed no-go conditions. Rollback authority should be named before the meeting, not during it.
What is a go-live rehearsal?
It is a full mock cutover run at the real times, so you learn how long each step takes and where it breaks. For workforce readiness, extend it so representative staff work realistic scenarios in the new environment while observers record where people struggle.
How early should readiness planning start?
The Washington State technology agency’s guidance says planning typically begins in earnest three to four months before deployment. Workforce items need the most lead time because rehearsing, fixing and rehearsing again takes more than one cycle.
Sources
- What Is Go-Live Readiness? Definition and Examples
- Project Management Partners Best Practices Summary (WaTech)
- EHR Go Live Planning Checklist (AHRQ)
- Bar-coded Medication Administration (AHRQ)
- Operational Readiness Planning
- ICAR Tool for General Infection Prevention and Control (CDC)
- Evaluate Training: Measuring Effectiveness (CDC)
- Entrustable professional activities for quality and safety (CDC)
- The Cutover and Go-Live Readiness Toolkit
- M3 Playbook, Key Task 4.16 (GSA)
- How to Confirm Your Service Is Ready for Go-Live
