From our experience in over 1,200 ERP and digitalisation projects in the DACH Mittelstand, we see a pattern: most go-lives perceived as failures did not fail on the cut-over weekend. They failed during hypercare and the 90 days after — because neither the KPI thresholds were agreed in advance nor the train-the-trainer cascade held. Treated as a single date, a go-live is a gamble; treated as a verifiable commissioning, it is manageable.
What Is a Go-Live? Definition and Boundary to Cut-Over
A go-live is the umbrella event of ERP commissioning, with three sub-phases: cut-over (technical switch-over, typically a long weekend), hypercare (two to four weeks of intensive support) and 90-day stabilisation (KPI verification). Most guides use cut-over and go-live interchangeably — a definitional error with expensive consequences.
In our cut-over definition we describe the technical migration — decommission the legacy system, migrate data, activate interfaces, release the new system. The cut-over takes place over a long weekend and ends with a go/no-go decision. The go-live is the larger event: it begins with the cut-over and ends only when the operational indicators — on-time delivery, period close, helpdesk load — are back at the prior level.
This hierarchy prevents the typical „but the cut-over went fine" discussion six weeks later, when on-time delivery is still 12 percentage points below the prior state. Four phases belong in every go-live architecture:
- Readiness check and go/no-go gate — hard KPI thresholds before the cut-over, not softened compliance checkboxes.
- Cut-over — the technical switch-over window, ideally on a production-light weekend.
- Hypercare — two to four weeks, with 24/7 standby in the first week and a daily incident meeting.
- 90-day stabilisation — structured KPI measurement at 30, 60 and 90 days against the pre-cut-over baseline.
The PMI PMBOK Guide on Project Closing and Transition anchors this separation methodologically: the Closing Process Group covers not just the technical transition, but the formal confirmation that the handover has actually taken place. From our practice: that confirmation belongs in a 90-day stabilisation report, not the cut-over report.
Why Go-Live Risks Are Critical for the DACH Mittelstand in 2026
Three drivers raise go-live risk in 2026: the S/4HANA modernisation wave, the skilled-staff shortage, and rising system-landscape complexity. From our experience, these three drivers compound during the first 30 days of hypercare.
First: the DACH ERP modernisation cycle is in full swing. The DSAG Investment Report 2026 documents for around 200 surveyed members that 42 percent of high and medium budgets flow into S/4HANA on-premises. The reasons for postponed go-live dates: system-landscape complexity, skilled-staff shortage and limited budgets — visible first on the go-live weekend.
Second: user satisfaction tilts during stabilisation. The Trovarit Study ERP in Practice 2024/25 rates vendor service, mobile usability and performance critically. These are the pain signals that surface in the helpdesk during the first 30 days.
Third: the operational baseline becomes more measurable. According to the Bitkom Industry 4.0 Study Report 2025, 71 percent of industrial companies with at least 100 employees use Industry 4.0 applications. That delivers a DACH baseline against which a Mittelstand company can compare its 30-, 60- and 90-day KPIs.
Case Study: Mittelstand Plant Manufacturer, About 420 Employees, Two Plants
With a southern German plant manufacturer, we saw how a clean cut-over weekend can still lead to a problematic go-live — because the train-the-trainer cascade had broken in one of two plants.
In our projects across DACH equipment-manufacturer engagements, we have seen this pattern. This southern German manufacturer with two plants and 420 employees cut over on a long weekend: migration without critical errors, interfaces activated. By Monday the system ran.
Three weeks later, the second plant — 90 kilometres away — showed rising ticket volume, on-time delivery 14 percentage points below baseline, and end users on Excel workarounds. The cause: two of three key users had left shortly before go-live. The remaining key user carried 78 end users alone — which does not work.
The correction: we transferred two key users from plant 1 to plant 2 for four weeks, brought in an external trainer, and extended hypercare to eight weeks. KPIs were measured separately per plant. After 90 days, on-time delivery was back at 87 percent. The lesson: a go-live without a train-the-trainer resilience plan is commissioning by sight. Architecture before software — including the training cascade.
What Go-Live Guides Leave Unsaid
Three points rarely in go-live checklists, but that we see across 1,200+ projects as first-order risk levers — belonging before the cut-over weekend, not after. Most ERP literature conflates cut-over and go-live; our practice treats them as nested events.
1. The 30/60/90-Day KPI Matrix With Hard DACH Thresholds
Most guides mention hypercare and stabilisation without concrete thresholds. Every ERP go-live in the Mittelstand needs a pre-agreed 30/60/90-day matrix: on-time delivery after 30 days at least 85 percent of the prior state; period close after 60 days back within two working days; helpdesk volume after 90 days below 50 percent of the first-week peak. These thresholds are agreed in writing before cut-over. Set later, they cannot be defended.
2. Train-the-Trainer as a Risk Lever, Not a Training Topic
Train-the-trainer is not a training topic — it is risk management. Heuristic: one fully trained key user per 20 to 25 end users, with two weeks of full presence before go-live and four weeks of elevated readiness after. With only one key user per location, the cascade is structurally fragile. This gap is closed by a resilience plan signed off before go-live, not by more PDFs. The Prosci ADKAR Model for ERP adoption provides the frame: Ability before go-live, Reinforcement after.
3. The Go/No-Go Heuristic With Minimum Criteria — Not Gut Feeling
The gate needs five minimum criteria: migration without open critical errors; UAT pass rate above 95 percent; training coverage above 90 percent of affected roles; all production-critical interfaces tested under production-like conditions; hypercare team fully staffed for four weeks. If criteria are softened, problems multiply during hypercare. The Microsoft Dynamics 365 Go-Live Checklist confirms this logic from a vendor perspective.
Our reading
A go-live without a KPI matrix, without a train-the-trainer resilience plan and without hard thresholds is methodologically a gamble — even if the cut-over night runs clean. Across 1,200+ projects: these three levers are at once the cheapest and most effective. They cost preparation time, not software. Skipping them buys problems into the first 90 days — where problems are most expensive.
How We Set Up a Go-Live Methodologically
We approach go-live projects in four phases: readiness check with go/no-go gate, technical cut-over on a production-light weekend, two-to-four-week hypercare with daily incident meeting, and structured 90-day stabilisation. Method before tool.
In our vendor-neutral ERP implementation work we treat the go-live as a verifiable commissioning. From our experience, a four-stage approach has proven itself:
- Readiness check and go/no-go gate — four to six weeks before cut-over. The check covers migration readiness, UAT status, training coverage, interface maturity and hypercare staffing. Five hard criteria; if one is missed, the cut-over is postponed.
- Cut-over — the technical switch-over window. Details in our cut-over definition.
- Hypercare — two to four weeks, 24/7 standby in week one, daily incident meeting, hypercare manager identical to the ERP project lead. Tickets classified by priority and functional area; KPI measurement daily.
- 90-day stabilisation — structured measurement at 30, 60 and 90 days. Comparison against the prior state, not an optimistic target.
The gate in practice
Before every cut-over we facilitate a joint gate meeting with the board, project team and key business-unit roles. The five criteria are reviewed, documented and signed off. The board has a defensible basis for the decision — no gut feeling, no pressure to meet a date.
The interlock with our broader ERP implementation approach ensures that the go-live is a logical consequence of a robust requirements specification and a methodical ERP selection. The difference from the usual approach: we set KPI thresholds before the cut-over, not after.
Common Mistakes in Go-Live Preparation
Four error patterns recur in Mittelstand go-lives — all avoidable if addressed before cut-over. Three are organisational, one methodological. None is rooted in the software — architecture before software applies to error prevention as well.
Mistake 1 — missing or weakened train-the-trainer phase. Training budgets are often the first thing cut. The result: too few key users, no resilience, end users without a contact. The most common reason for escalating helpdesk load in the first 30 days. The COMPUTERWOCHE analysis on ERP project failure names missing competencies as a recurring risk item.
Mistake 2 — softened go/no-go gate. Date discipline beats functional assessment. An open UAT issue becomes a residual point, an under-staffed hypercare team is compensated with overtime. These mistakes multiply during hypercare.
Mistake 3 — go-live before month- or year-end without a shadow run. Go-live before month-end only after two period-close shadow runs. Go-live immediately before year-end never.
Mistake 4 — no pre-agreed KPI matrix. Without 30/60/90-day thresholds, project success remains a matter of perception. The stabilisation phase ends in disarray.
Our reading
The mistakes are organisational and methodological — and that is where the lever of vendor-neutral consulting lies. Staff turnover in the business units underscores the train-the-trainer risk. A go-live is the transition from project mode into regular operations, and that transition needs a methodological bracket.
Frequently Asked Questions
The cut-over is the technical switch-over window — usually a long weekend. The go-live is the umbrella event: cut-over weekend, hypercare phase (two to four weeks) and 90-day stabilisation. The go-live ends only when the indicators are back at the level before the cut-over or above.
Two to four weeks, depending on functional scope, number of locations and interface complexity. First week: 24/7 standby with a daily incident meeting; following weeks: a gradual transition to regular hours. The hypercare manager is the same person as the ERP project lead — personnel continuity beats a separate hypercare role.
Both have their place. Big-bang fits homogeneous process landscapes and manageable location counts. Phased rollout fits heterogeneous processes or limited hypercare capacity. The decision follows from risk analysis — we recommend the variant in which the train-the-trainer cascade reliably carries each step.
The cascade is the most underestimated risk lever in the Mittelstand. Heuristic: one fully trained key user per 20 to 25 end users, two weeks of full presence before go-live and four weeks of elevated readiness after. With only one key user per location, the cascade is fragile — no backup, and end users fall back to Excel. Prosci ADKAR describes this as the Ability and Reinforcement phase.
Next Steps
Before the planned go-live, a four-to-six-week readiness check is worth the effort: KPI matrix agreement, a train-the-trainer resilience review per location, and a go/no-go gate with five minimum criteria. From our experience in the DACH Mittelstand, this is the most effective risk hedge before the cut-over.
More in our vendor-neutral ERP consulting and the ERP implementation section. We also recommend our wiki entry on the cut-over plan. Further articles in our insights; a conversation via the contact page. We assess go-live readiness along method, KPIs and risk levers — not vendor preference.
30 minutes with Dreher Consulting
A structured review of your go-live readiness — KPI matrix, train-the-trainer resilience plan and the go/no-go gate with five minimum criteria, vendor-neutral and drawn from over 1,200 projects in the DACH Mittelstand.
