Why this matters. An ERP implementation doesn't fail at the go-live weekend — it fails in the first 90 days afterwards, when no one is doing hypercare any more and daily operations break. The Bitkom maturity model for digital business processes 2.0 provides the reference for evaluating implementation readiness — both before and after go-live.
When this approach fits — and when it does not
This approach fits when:
-
Legacy data is cleaned before the project starts — not during the cutover weekend;
-
Power users are named in each business area before training begins;
-
Hypercare is set up as a funded 90-day programme, with a daily triage meeting.
This approach does not fit when:
-
The go-live date is politically fixed without documented go/no-go criteria;
-
Day-to-day operations during hypercare fall entirely back on the end users;
-
Data migration is treated as an IT task instead of a business-area responsibility.
How an ERP implementation runs — the five steps
A defensible ERP implementation follows five steps with explicit handover logic. The SCOReX methodology structures the phases so that the critical 90 days after go-live are treated with the same rigour as the preparation — hypercare is project work, not line work.
-
Step 1 — Legacy-data cleanup as a pre-phase: measure data quality, resolve duplicates and orphaned records, document migration rules. Output: cleaned migration dataset with quality metrics per table.
-
Step 2 — Blueprint with named accountability: target processes signed off by process owner, interfaces and reporting paths agreed. Output: signed blueprint with RACI per main process.
-
Step 3 — Build, test and training plan: customising against the blueprint, integrated tests on real data, power-user training before end-user training. Output: signed-off customising state and training roadmap.
-
Step 4 — Cutover weekend with fallback: minute-by-minute cutover plan, go/no-go criteria in writing, rollback path defined. Output: go-live with documented decision basis.
-
Step 5 — Hypercare for 90 days: daily triage, escalable ticket queue, power-user hotline, post-go-live re-training instead of pre-training. Output: stable operations and a written hypercare close-out.
A common mistake and how to avoid it
A mid-sized wholesaler in northern Germany with around 180 employees ran a demanding ERP project cleanly through to go-live — then released the project team back to day-to-day work on the Monday after cutover. By Wednesday backward scheduling was returning the wrong dates, by Friday stock levels for four product groups did not reconcile. No one had capacity left because the hypercare budget had already been spent. Six weeks later the users' trust in the system was gone.
In practice, three disciplines decide the outcome: legacy-data cleanup as a stand-alone pre-phase, a cutover plan with documented go/no-go criteria (see also our guide to a successful ERP implementation), and a hypercare programme that treats the first 90 days as a project phase, not as a complaint queue.
What to do next
If you want to test how resilient your implementation plan is across the 90 days after go-live:
-
Name a power user and a deputy for each main process.
-
Reserve a dedicated 90-day hypercare budget — separate from the project budget.
-
Define three hard no-go criteria for the cutover before the weekend begins.
If you want a structured second view on this part of the programme, we can scope the 90-day hypercare logic with you in twenty minutes — the cost of an ERP implementation depends directly on how this phase is run.
FAQ
Six to eighteen months. Cloud implementations frequently land around nine months, on-premises programmes at twelve months and above. The decisive factors are data quality, clear process accountability, and a funded hypercare window.
Hypercare. Daily triage meetings, an escalable ticket system, a power-user hotline, and targeted re-training. Treating hypercare as a complaint queue costs you user trust — and the implementation's success.
Either works when go/no-go criteria are documented and a rollback path exists. Big-bang reduces parallel-running cost; a phased roll-out limits risk per site. The format does not decide success — discipline does.
