Software Go-Live Checklist
A go live checklist for launching a new system or replacing an old one: cutover plan, data migration, user readiness, hypercare and decommissioning steps.
- Typical schedule per go-live
- The checklist 5 sections, 23 items
- Variables
{{system}}{{go_live_date}}
Use this checklist when a new system goes live for real users for the first time, or when it replaces an old one. Typical cases are a new CRM, ERP or ticketing tool, a rebuilt customer portal, or an internal app moving off spreadsheets. A go-live is a one-off event with a cutover: data moves, users switch and the old system is frozen. That makes it different from a normal release, and the main risks are about people and data, not code.
Who owns it
A go-live lead, usually the project manager or the technical lead, owns the run and chairs the go or no-go meeting. The business owner of the system signs off on data and user readiness. Assign the data migration, training and support items to the people who actually do them, so the run shows who confirmed what.
Common pitfalls
- No cutover rehearsal. Run the full data migration at least once on a copy before go-live day, and time it. The real run always takes longer than the estimate.
- Users trained too early or not at all. Training a month before go-live is forgotten. Train close to the date and give people a short guide for the first week.
- The old system stays writable. If people can still enter data in the old system after cutover, you get two sources of truth. Make it read-only at a set time.
- No hypercare period. The first days after go-live need extra support and quick fixes. Plan who is on hand before the date, not after the first complaints.
- No fallback decision point. Agree in advance until when a return to the old system is still possible, and who makes that call.
The checklist: Go-live: {{system}} on {{go_live_date}}
Readiness
-
Go-live date
{{go_live_date}}and cutover window are confirmed with the business owner -
User acceptance testing is signed off by the business owner
-
Open defects are reviewed and none of them block go-live
-
User accounts, roles and permissions are set up and checked with a sample of users
-
Integrations with other systems are tested end to end with production-like data
-
Backups, monitoring and alerting are in place for
{{system}}
Data and cutover plan
-
Cutover plan lists each step, its owner and its expected duration
-
Full data migration has been rehearsed on a copy and timed
-
Data validation rules are agreed, such as record counts and spot checks of key records
-
Fallback plan is written down, with the latest point at which it can still be used
People
-
Key users are trained and have a short guide for the first week
-
Support contacts and the escalation path are communicated to all users
-
Go-live announcement with date, downtime and what changes is sent to users
Cutover
-
Go or no-go decision is made and recorded with the names of the decision makers
-
Old system is set to read-only or data entry is frozen at the agreed time
-
Final data migration is run and its log is checked for errors
-
Migrated data is validated against the agreed counts and spot checks
-
Integrations, DNS or links are switched to
{{system}} -
Key users confirm they can log in and complete their main tasks
Hypercare and closure
-
Hypercare team and hours are staffed for the first days after go-live
-
Issues raised in hypercare are logged, prioritised and tracked to closure
-
Handover from the project team to the regular support team is done
-
Old system is archived and decommissioned after the agreed retention period optional
Checklist as Markdown
Frequently asked questions
What is a cutover plan?
A cutover plan is the step-by-step schedule for switching from the old system to the new one. It lists each step, its owner, its expected duration and the checks that confirm it worked. It also states the latest point at which you can still return to the old system.
What is hypercare after go-live?
Hypercare is a short period of extra support right after go-live. The project team stays on hand to fix issues fast, answer user questions and watch data quality. It ends with a planned handover to the regular support team.
When should we decide to postpone a go-live?
Postpone when a blocking defect is open, when the rehearsal showed data problems you have not fixed, or when key users are not ready. Make the decision in a go or no-go meeting a day or two before the date, using agreed criteria. Postponing early is much cheaper than rolling back after users have started entering data.
Updated