Go-Live Plan: 12-Week Template With Cutover, Go/No-Go and Hypercare
9 min read ยท 2026-10-25
A go live plan is the part of a project plan that takes a new system from tested to used in production. It sets the go-live date, the readiness criteria, the cutover steps hour by hour, who decides go or no-go, how you roll back if something fails, and how you support users in the first weeks.
The template below covers the last 12 weeks of an implementation, from readiness planning to the end of hypercare. It fits ERP, CRM, HR, finance and other business system launches, and it works with phased or big bang rollouts. It is written for project managers, PMO leads, IT leads and business owners who must make the launch happen and explain its status to leadership.
The roadmap at a glance
Goal: The new system is live on the planned date, business operations run on it without major disruption, and support has moved from the project team to the normal support model. Duration: 12 weeks
Readiness planning (Weeks 1-2)
Agree what ready means and who decides.
- Write go-live readiness criteria for testing, data, training, support, security and business sign-off.
- Choose the rollout approach: big bang, phased by site or module, or parallel run.
- Name the cutover manager, the go/no-go decision makers and the hypercare lead.
- Pick the cutover window with the business, avoiding month-end, payroll and peak sales periods.
Milestone: Readiness criteria, rollout approach and cutover window approved by the steering committee.
Final testing and data rehearsal (Weeks 3-6)
Prove the system and the data are ready for real work.
- Finish user acceptance testing and fix or accept every open critical defect.
- Run the first mock data migration and reconcile record counts and balances with the business.
- Test integrations end to end with partner systems and confirm their teams will be on call.
- Run a performance test with realistic volumes.
Milestone: UAT signed off by business owners and the first mock migration reconciled without critical errors.
Training and change readiness (Weeks 4-9)
Make sure people can do their jobs in the new system on day one.
- Train key users first, then end users by role, using the final configuration.
- Publish quick reference guides for the most common tasks.
- Send go-live communications: what changes, when, where to get help.
- Confirm super users in each team who will help colleagues during hypercare.
Milestone: Every user with a role in the new system trained, and super users named for each team.
Cutover rehearsal and go/no-go (Weeks 7-9)
Rehearse the cutover and decide formally whether to go.
- Write the cutover runbook: every task, owner, start time, duration and check, plus rollback points.
- Run a full dress rehearsal of the cutover and time each step.
- Update the runbook from the rehearsal and confirm the timeline fits the window.
- Hold the go/no-go meeting and review each readiness criterion with evidence.
Milestone: A signed go decision recorded in the meeting notes, or a no-go with a new date and the actions to fix.
Cutover and go-live (Week 10)
Switch the business to the new system on the planned date.
- Freeze changes in the old system and run final data extracts at the planned time.
- Load and reconcile data, switch integrations and open user access.
- Run smoke tests of the most critical processes, such as creating an order or posting an invoice.
- Confirm go-live with the business owners or trigger the rollback plan.
Milestone: Business owners confirm critical processes work in production and the old system is set to read-only.
Hypercare and handover (Weeks 10-12)
Support users closely until operations are stable, then hand over.
- Staff a hypercare desk with the project team, key users and vendor support.
- Hold a daily triage call on issues, ranked by business impact.
- Track exit criteria such as open critical issues, ticket volume and first month-end close.
- Hand over to the support team with documentation and open items.
Milestone: Exit criteria met and the support team signs the handover.
Go-live readiness criteria
Readiness criteria turn the go/no-go meeting from a debate into a check. Write them in week one, agree them with the steering committee, and attach an owner and the evidence for each. Then report against them every week, so nobody is surprised at the decision meeting.
Use clear thresholds where you can. Not ready because testing feels incomplete leads to an argument. Not ready because three critical defects are still open leads to a decision.
- Testing: UAT signed off, no open critical defects, workarounds documented for high ones.
- Data: last mock migration reconciled and signed off by data owners.
- Integrations: end-to-end tests passed and partner teams on call for the cutover.
- People: users trained, super users named, communications sent.
- Support: hypercare rota, ticket categories and escalation paths in place.
- Business: each process owner signs that their team can operate on the new system.
- Rollback: plan tested and decision points agreed.
Example: a filled-in go-live plan
Picture a distribution company replacing its order management and finance system across two warehouses. The steering committee chose a big bang go-live over a long weekend, two weeks after month-end close.
Every line has an owner and a check, and the cutover has a clear point of no return. That point tells everyone when rollback is still cheap and when it is not.
- Weeks 1-2 (project manager): readiness criteria and big bang approach approved, cutover window set for a Friday evening to Monday morning. Check: steering committee minutes.
- Weeks 3-6 (test lead and data lead): UAT closed, two mock migrations reconciled, carrier and bank integrations tested. Check: sign-off from finance and warehouse leads.
- Weeks 4-9 (change lead): 160 users trained by role, 12 super users named. Check: training completion report.
- Weeks 7-9 (cutover manager): full dress rehearsal finished within the window, go decision signed by the sponsor, CFO and operations director. Check: signed go/no-go record.
- Week 10 (cutover manager): Friday 6 pm freeze, Saturday load and reconcile, Sunday smoke tests, point of no return Sunday 2 pm, users live Monday 7 am. Check: first orders shipped Monday.
- Weeks 10-12 (hypercare lead): daily triage, first month-end close on the new system. Check: support handover signed.
How to write the cutover runbook
The cutover runbook is the hour-by-hour script for the go-live window. Build it in a spreadsheet such as Excel or Google Sheets so everyone can follow it live. Give each row an ID, a task, an owner, a backup owner, a planned start, a duration, a dependency, a check and a status column.
Mark the rollback points clearly. Before each one, the cutover manager confirms with the decision makers whether to continue. After the point of no return, problems are fixed forward. Rehearse the runbook at least once, time every step and add a buffer before you trust the window.
- Pre-cutover: freeze dates, communications, access checks and backups.
- Extract and load: final data extracts, loads and reconciliation sign-offs.
- Switch: integrations, interfaces, printers, user access and old system set to read-only.
- Verify: smoke tests by business owners with named test cases.
- Decision: go-live confirmation or rollback, with the names of who decides.
Who owns what
Go-live needs one person in charge during the window, and clear rights to decide. Write these names into the runbook and the communication plan, with phone numbers for the cutover weekend.
Keep the decision group small. Three or four people who own the business outcome are enough to decide go, no-go or rollback.
- Executive sponsor: chairs the go/no-go meeting and owns the final decision.
- Project manager: owns the go-live plan, readiness tracking and status reporting.
- Cutover manager: runs the runbook during the window and calls the checkpoints.
- Business process owners: sign off UAT, data and smoke tests for their area.
- Data lead: extracts, loads and reconciliation.
- IT and infrastructure: environments, access, backups and integration switches.
- Vendor or system integrator: technical support during cutover and hypercare.
- Hypercare lead and super users: first-line help and issue triage after go-live.
How to run the go/no-go meeting
Hold the meeting a few days before the cutover starts, early enough to stop without losing work. Walk through each readiness criterion with its owner and evidence, then each open risk and its fallback. End with a clear question to each decision maker: go or no-go, and why.
Record the decision, the conditions attached and the names of the people who decided. A conditional go is fine, such as go if the last integration test passes by Thursday noon. Write the condition, the owner and who confirms it.
How to present it to leadership
Leaders need one view: the six phases on a timeline with the go-live date, a status per readiness criterion, and the top three risks with their fallbacks. Add what you need from them, such as freezing other changes in the cutover window or approving overtime.
Leave out defect lists and runbook detail. If a criterion is red, show the gap, the fix and the date it will be green. If the date is at risk, say so early and give options, such as a later date or a phased rollout, with the cost and risk of each in plain words.
Hypercare: exit criteria and handover
Hypercare is the period of extra support right after go-live. Plan it as part of the go-live plan, with a start, an end and exit criteria agreed in advance. Many teams plan two to six weeks, and often include the first month-end close on the new system.
Exit hypercare when the numbers say so, not when the project team is tired. Then hand over to the support team with a known issues list, documentation and named contacts.
- No open critical issues and a falling number of high issues.
- Ticket volume back to a level the support team can handle.
- First key business cycle completed, such as month-end close or first payroll.
- Support team trained and documentation handed over.
Common mistakes to avoid
- Picking a go-live date before testing is done turns the date into pressure to skip steps, so tie the date to readiness criteria from week one.
- Skipping the dress rehearsal leaves the cutover timeline untested, so run at least one full rehearsal and time every step.
- Writing a rollback plan without decision points makes rollback impossible in practice, so mark rollback points and the point of no return in the runbook.
- Training users months before go-live means they forget, so train close to the date on the final configuration.
- Going live during month-end or peak season leaves no room for problems, so choose a quiet window with the business.
- Ending hypercare on a fixed date even when issues are open frustrates users, so use exit criteria agreed in advance.
Frequently asked questions
What should a go-live plan include?
It should include readiness criteria, the rollout approach, the cutover runbook with owners and timings, the go/no-go process, a rollback plan, communications, and hypercare with exit criteria. Add a contact list for the cutover window and the names of decision makers.
What is the difference between a go-live plan and a cutover plan?
The cutover plan is the detailed script for the switch itself, usually hour by hour over a weekend or a night. The go-live plan is wider: readiness, training, the decision process, cutover and hypercare. The cutover runbook sits inside the go-live plan.
What is a go/no-go meeting?
It is a formal meeting before cutover where decision makers review each readiness criterion with evidence and decide whether to proceed. The outcome is go, conditional go or no-go with a new date. The decision and its conditions are written down and signed.
How long should hypercare last after go-live?
Many teams plan two to six weeks, depending on system size and how many business cycles need to run once. Include at least one key cycle, such as month-end close. End hypercare when the exit criteria are met.
What is a rollback plan?
A rollback plan explains how to return to the old system if the go-live fails. It lists rollback points, the steps to restore the old system, who decides and the latest time rollback is possible. Test it during the dress rehearsal.