Go-Live

What Is Go-Live?

Go-live is the moment a new system, platform, or archive officially becomes the active environment users rely on, replacing whatever they were using before. It’s the mirror image of cutover: cutover describes users leaving the old system and go-live describes the new environment stepping into that role, and in most projects the two happen at the same scheduled moment.

For a replacement application, go-live means the new system is now handling live transactions and daily operations. For a retirement scenario where an application is being archived rather than replaced, go-live has a slightly different meaning: it’s the point at which the archive itself becomes the environment users query when they need historical information, since the original application is no longer available for that purpose. Either way, go-live marks the boundary after which the new environment is expected to be fully functional and reliable, not still being tested or refined.

Because go-live is the most visible moment in any decommissioning or migration project; it’s when users first directly experience whatever was built, it’s typically preceded by a defined hypercare period: a window of heightened monitoring and support immediately after go-live, during which the project team is on standby to quickly resolve issues before they affect broader user confidence in the new environment or archive.

Key Points

• The new environment’s side of the cutover moment. Go-live and cutover typically happen simultaneously but describe opposite perspectives; one is the new system starting, the other is the old system stopping.
• Means something different for an archive than a replacement application. For a replacement system, go-live means live transactions begin. For an archive, go-live means it becomes the destination for historical queries, since there’s no ongoing transaction processing involved.
• Marks the end of testing, not the start of it. By go-live, the new system or archive is expected to be fully validated and functional, discovering major issues after go-live is a sign of insufficient testing beforehand, not a normal part of the process.
• Usually followed by a hypercare period. A defined window of heightened monitoring and rapid support immediately after go-live is standard practice, since early issues are far cheaper to catch and fix than ones discovered weeks later.
• A single date with outsized visibility. Go-live is the moment most users actually notice a migration or decommissioning project happened, which is why it tends to get disproportionate planning attention relative to the less visible extraction and validation work that made it possible.

Common Use Cases

🚀 New ERP go-live after a legacy migration

Users begin processing live transactions in a new ERP platform on the scheduled go-live date, with the legacy system’s historical data already archived and the legacy environment moved into a locked-down, read-only state.

🛡️ Hypercare monitoring immediately after go-live

For a defined period after go-live — commonly two to four weeks — the project team maintains heightened monitoring and rapid response capacity to resolve any issues users encounter in the new environment before they affect broader adoption.

🗄️ Archive go-live for a retired application

When an application is retired outright with no replacement, the archive’s go-live is the point at which business users and auditors are directed to query the archive for historical information, since the original application is no longer accessible.

Go-Live vs. Related Concepts

Go-live is closely tied to two related terms describing the same broader transition event.

CUTOVER

The old system’s side of the same transition — users stopping use of the legacy environment. Cutover and go-live are frequently used interchangeably, though they describe opposite ends of the same event.

DATA FREEZE

The step that typically precedes both cutover and go-live, stabilizing the legacy system’s data before final extraction so the new environment or archive starts from a clean, validated data set.

DECOMMISSIONING PLAN

The broader runbook that schedules go-live as one specific milestone within the full sequence of extraction, validation, cutover, go-live, and eventual shutdown.