What is ERP go‑live?

Go‑live is the moment when the new ERP system is made available for production use. It involves switching from legacy systems to the new ERP, migrating final data, and starting daily operations.

What are the different go‑live approaches?

Common approaches: Big Bang (all at once), phased (by module or location), and parallel run (both systems operate temporarily). The choice depends on risk tolerance and complexity.

Hypercare is the period immediately after go‑live (typically 2‑4 weeks) when the project team provides intensive support to users, resolves issues quickly, and ensures stabilization.

Go‑live strategy

From ERPEDIA, the independent ERP knowledge base

Go‑live is the moment when the new ERP system is made available for production use. It is the culmination of months or years of work – but also the beginning of a new phase. A well‑planned go‑live strategy minimises business disruption, ensures data integrity, and sets the stage for successful adoption. This article covers cutover planning, go‑live approaches, go‑no go criteria, and hypercare.

Contents

1. Go‑live approaches
2. Cutover planning
3. Go‑live checklist
4. Go‑no go criteria
5. Go‑live day
6. Hypercare & stabilization
7. Rollback & contingency
8. Common pitfalls

1. Go‑live approaches

Three main strategies for transitioning to the new ERP:

Approach	Description	Pros	Cons
Big Bang	Switch from legacy to new ERP at a single point in time (over a weekend).	Fastest, no dual maintenance.	Highest risk; any issue affects entire business.
Phased	Implement by module (e.g., finance first, then sales) or by business unit/location.	Lower risk, learn as you go.	Longer overall timeline, integration complexity.
Parallel Run	Both old and new systems operate simultaneously for a period.	Lowest risk; can compare results.	Double work for users, expensive.

The choice depends on company size, complexity, risk tolerance, and resources.

2. Cutover planning

Cutover is the detailed sequence of tasks to switch to the new system. A typical cutover plan includes:

T-2 weeks Freeze non‑critical changes, final data cleansing, user training completion.

T-1 week Final UAT sign‑off, communication to organisation, prepare infrastructure.

T-1 day Stop transactions in legacy system, extract final data, begin data migration.

T-0 (Go‑live) Validate migrated data, open ERP for business, users start working.

A detailed cutover plan assigns owners and timelines for every task, down to the hour.

3. Go‑live checklist

Essential items to confirm before go‑live:

UAT completed and signed off.
All critical defects fixed and re‑tested.
Data migration dress rehearsals successful.
User training completed.
Security roles and access provisioned.
Interfaces and integrations tested.
Backup and recovery procedures ready.
Hypercare team in place.
Communication sent to all users.

4. Go‑no go criteria

Before the final decision, the steering committee reviews objective criteria:

Criteria	Green (Go)	Red (No Go)
UAT results	≥95% pass rate, no critical defects	<90% pass rate or open critical defects
Data migration	All dry runs successful, reconciliation passed	Reconciliation errors in last dry run
User readiness	Training completed, confidence high	Low attendance, users uncomfortable
Infrastructure	All systems ready, performance acceptable	Performance issues, outages

If any red condition exists, the project team presents a mitigation plan or recommends delaying.

Rule: Never go live with known critical defects. It's cheaper to delay a week than to fix a crisis after go‑live.

5. Go‑live day

Activities on the day:

Early morning: Final data migration, validation.
Morning: System opened to pilot group or all users (depending on strategy).
All day: Hypercare team on standby, war room active.
End of day: Quick status meeting, plan for next day.

Celebrate! But keep the team focused.

6. Hypercare & stabilization

Hypercare is the period (typically 2‑4 weeks) after go‑live with intensified support:

On‑site/remote support: Experts available in person or via hotline.
Daily stand‑ups: Review issues, prioritize fixes.
Quick turnaround: Critical issues addressed within hours.
User coaching: Super‑users and trainers provide hands‑on help.

Hypercare team: Includes functional consultants, technical support, super‑users, and the project manager. Often works extended hours.

After hypercare, support transitions to the regular IT/service desk.

7. Rollback & contingency

Despite best efforts, a rollback plan is essential. It defines:

Triggers for rollback (e.g., critical failure affecting business).
Steps to revert to legacy system.
How to preserve data from the failed go‑live.

Most rollback plans are never executed – but having one reduces anxiety and risk.

8. Common pitfalls

Inadequate cutover testing: First time should not be at go‑live.
Ignoring people readiness: Users not trained or resistant.
Understaffed hypercare: Team burns out, issues backlog.
No clear go‑no go criteria: Political decision overrides data.
Forgetting to communicate: Users don't know when to start.

Key Takeaways

Choose a go‑live approach (Big Bang, phased, parallel) based on risk and complexity.
Cutover planning must be detailed, with hourly tasks and owners.
Go‑no go criteria should be objective – never override with politics.
Hypercare provides intensive support for the first weeks.
Always have a rollback plan, even if you never use it.

How long does hypercare last? Typically 2‑4 weeks, but can extend for complex implementations. Some issues may require longer support.

What if we need to roll back? The rollback plan is executed – but it's costly. Prevention is better.

Should we go live on a Monday? Often Friday or weekend is chosen to allow a buffer before business peak.

Continue Reading in ERPEDIA

ERPEDIA is maintained by Professionals Lobby as an independent ERP knowledge initiative focused on reducing ERP implementation risk in the UAE and GCC.
For structured, vendor‑neutral ERP advisory → Speak with an independent ERP advisor.