Go-Live

Go-live is the point at which a new system starts being used for real work and becomes the system of record. It is preceded by a go/no-go decision against agreed criteria, and followed by verification, business validation and a defined support arrangement. It sits inside the wider cutover window rather than being the whole of it.

Go-live is a moment with conditions attached. The conditions are what make it a controlled event rather than a deployment: a decision taken against criteria agreed in advance, evidence that the system works, a support model that is staffed from that moment, and a communicated position on what to do when something does not work.

What it contains

What sits around a go-live is fairly consistent regardless of the system.

The go-live checklist guide sets out the technical, data, business, operational and governance checks in more detail, and the Go Live Readiness Deck is the format most organisations use to present the position to the deciding forum.

How it is used

Go-live functions as a fixed point that everything else is planned against. Testing windows, freeze dates, training, migration rehearsals and support staffing are all scheduled backwards from it. That is also why moving it is expensive: the date is a dependency for a large number of parties, several of whom are outside the project.

In reporting, go-live readiness is normally tracked as a scorecard by workstream — technical, data, business, operational — updated weekly in the run-up, so that the readiness position at the decision meeting is a continuation of what has been reported rather than a surprise.

Where it goes wrong

The common failure is that go-live is treated as the finish line. The project team stands down, the support organisation has not been staffed for the volume of early questions, and the first week is absorbed by people who were meant to be released.

The second is undefined success. If nobody wrote down what "live and working" means, the system is declared live at deployment and the problems surface on the first business day. The third is a go-live date that has been treated as immovable for so long that criteria are waived one by one to protect it, without anyone assessing the waivers together.

The fourth is a go-live scheduled without regard to the business cycle. Landing a finance system in the week of a period close, or a retail change during a peak trading week, adds load precisely where there is no capacity to absorb it. The date is usually negotiable earlier than people assume, and much less negotiable once it has been communicated to customers, regulators or a vendor whose staffing has been booked around it.

Related terms

See also go/no-go decision, hypercare and smoke test.

Questions

What is the difference between go-live and cutover?

Cutover is the whole controlled transition, including freeze, migration and verification. Go-live is the point inside it at which the new system starts being used for real work.

What has to be true before go-live?

Whatever the agreed exit criteria say. Typically testing complete, defects within threshold, data reconciled, users trained, support staffed and a rollback position stated.

Who decides that a system goes live?

The forum named in the cutover plan, usually chaired by the business owner, with technical, data, business and support leads each answering for their own criteria.

What happens immediately after go-live?

Technical verification, then business validation by named users, then the start of the agreed support arrangement — commonly hypercare or early life support.

Glossary · All 36 templates