Go-Live
A go-live is the cutover date on which a new ERP system is switched from test to production and every user starts working in it. From that moment on, the real business processes – orders, postings, stock – run in the new system.
The go-live is the point at which a new or fundamentally changed ERP system is moved from the project and test world into productive operation – the moment from which a company's real business transactions are handled exclusively in the new system. With the go-live, the trial phase ends and the real thing begins: from now on, customer orders, purchase orders, stock movements and postings are recorded productively in the new ERP, and the legacy system is decommissioned for day-to-day operations.
The term comes from IT project management and denotes not so much a long period as a clearly scheduled event – often placed on a weekend or a low-revenue cutover date. The go-live is therefore the most visible and riskiest milestone of an ERP implementation: everything prepared during configuration, data migration and testing has to come together at this point. It is preceded by a formal go/no-go decision and followed by an intensive stabilization phase.
At a glance
- Go-live = the cutover date of the switch from test to production of the ERP
- An event, not a period – usually placed on a weekend or low-revenue days
- Its starting point is a formal go/no-go decision based on fixed criteria
- Immediately afterwards comes stabilization ("hypercare") with heightened support
- Success depends on data quality, test depth, the cutover plan and user readiness
What a go-live means
The go-live marks the boundary between project and operations. Until this point, the new ERP exists only as a configured and tested system in a protected environment; the actual business processes still run in the legacy system or in previous isolated solutions. With the go-live, this relationship is reversed: the new system becomes the leading system ("system of record") in which postings, planning and invoicing are done bindingly.
A go-live is therefore more than a technical switch. It comprises the release of the production system, the final transfer of current data, the activation of users and interfaces, and clear communication to everyone involved – internally and, in part, to customers and suppliers. From the moment of going into production, every error counts double, because it immediately affects real orders, deliveries and payments.
How a go-live proceeds
A go-live follows a tightly timed sequence that is planned long in advance and often tested in a dry run. The individual steps build on one another; a delay at one point pushes back the entire switch.
Cutover and final data transfer
The core of the go-live is the so-called cutover – the actual switchover, usually over a weekend. A cutover plan accurate to the minute or hour lists every step: from the final data export out of the legacy system, through the final data migration of master and open transaction data (open orders, stock, open items), to the technical release of the new system. A prior dry run ("mock cutover") ensures that the sequence and time requirements hold up when it counts.
Go/no-go decision
Shortly before going into production, the project team and management make a formal go/no-go decision. Using a checklist, they verify that all prerequisites are met: successful tests and sign-off, migrated and plausibility-checked data, trained users, functioning interfaces and a support team ready to go. If even a single critical criterion fails, the go-live is postponed rather than risked – a "no-go" is a legitimate and often wise decision.
Hypercare and stabilization
Immediately after the go-live, the stabilization phase begins, often called "hypercare": an extended support team stands ready to resolve questions, errors and special cases in the first productive days and weeks right away. Only once the central processes – from goods receipt to invoice – run reliably does the system move into normal routine operation.
Why the go-live matters
The go-live determines whether months of project work pay off. A cleanly prepared go-live ensures that the switch succeeds without data loss, process standstill or delivery failures; a rushed go-live, by contrast, can distort stock, lose orders and permanently damage the workforce's trust in the new system.
Because the go-live has an outward effect – late deliveries or faulty invoices hit customers immediately – it is also a reputational risk. For this reason, dates are deliberately placed in low-revenue phases, contingency plans (fallback to the legacy system) are prepared and reserves are factored in. The go-live is therefore not only a technical but also a business milestone.
Go-live, rollout and ERP implementation distinguished
The terms are often mixed up, but they denote different scopes. The ERP implementation is the entire project, from conception through configuration and testing to operation. The ERP rollout is the deployment phase within it – the transfer of the finished system into live operation, possibly across several sites. The go-live is the concrete moment of switching over within this rollout.
Put simply: the implementation is the whole thing, the rollout is the deployment phase, and the go-live is the cutover date of the switch. With a staggered rollout there can be several go-live dates – for example one per site or legal entity. The strategy also shapes the go-live: with a big bang the entire system goes live on a single cutover date, whereas in parallel operation the legacy and new systems run side by side for a while to safeguard the switch.
Success factors and DACH specifics
Whether a go-live succeeds is decided before the cutover date: by the data quality of the migration, the depth of testing, the readiness of the trained users and the accuracy of the cutover plan. Added to this are active change management that brings employees along, clear responsibilities for switchover day and a defined fallback plan in case critical processes do not start up.
In the DACH region, the go-live must additionally be safeguarded in accounting and legal terms. The switch on the cutover date must be documented in a way that satisfies the principles of proper bookkeeping (GoBD in Germany, comparable requirements in Austria and Switzerland); the transfer of tax- and accounting-relevant data as well as the audit-proof retention of the legacy system are a mandatory part of go-live planning. Before going into production, the connection to DATEV or BMD, the correct VAT treatment and the e-invoicing obligation must also be checked so that the first productive posting and invoicing run in the new system proceeds cleanly.
Example
Example: a wholesaler switches its new ERP to live over a weekend
A mid-sized B2B wholesaler wants to replace its historically grown merchandise management system with a unified ERP. The go-live is deliberately placed on a long weekend when hardly any orders come in. On Friday evening after close of business the cutover begins: the legacy system is locked for postings, a final export of item, customer and open order data runs, and then the data migration into the new system starts.
On Saturday morning the team checks the migrated stock against a sample inventory count, reconciles open items and tests the interfaces to the shop and the shipping service provider. In a go/no-go round on Sunday, the project management and management release the system because all critical criteria are met. From Monday morning, all departments work productively in the new ERP. In the first week the core team sits together in hypercare and resolves questions from the warehouse, purchasing and accounting right away – after two weeks routine operation runs stably.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about Go-Live in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.