Go-live is the moment your organization stops using the old system and starts running its business on the new ERP. It is also the moment when months of configuration, data migration, training, and testing either produce the stable, productive outcome you planned for — or reveal the problems you did not catch in time.

This guide walks through everything your team should verify before go-live, the decision between a parallel run and a hard cutover, and what to prioritize in the first thirty days after the system launches.

Why Go-Live Preparation Deserves Its Own Focus

ERP projects have a long project phase where the system is being configured and tested in a development or staging environment. Throughout that phase, errors can be corrected without business consequence. On go-live day, errors in a live production environment affect real transactions, real customers, and real financial records.

The stakes of a poorly prepared go-live are high: orders that cannot be processed, invoices that cannot be sent, payroll that cannot run, inventory that cannot be tracked. Any of these failures in the first days after go-live is not just an IT problem — it is a business-continuity issue.

A structured go-live checklist ensures that the readiness criteria your team agreed on at the start of the project are actually met before you commit to going live.

Technical Checks

Technical readiness is the foundation. If the system is not stable, correctly configured, and accessible, nothing else matters.

Technical Check	Responsible Party	Verify By
Production environment provisioned and stable	Partner / IT	Functional sign-off
All integrations tested end-to-end in production	Partner	Integration test results
Performance tested under expected load	Partner / IT	Load test results
Backup and recovery procedures verified	IT	Backup restore test
SSL certificates and security configurations confirmed	IT	Security scan
User access provisioned for all go-live users	IT / Partner	Access review
Role-based permissions verified against job functions	IT / Partner	Permission audit
Print templates for orders, invoices, POs confirmed	Partner	Document samples
Email notifications from system configured and tested	Partner	Test sends
System monitoring and alerting active	IT	Alert test

Working through this list at least two weeks before go-live — not two days before — gives you time to fix problems without emergency pressure.

Integration Testing in Production

Many ERP projects do integration testing in a staging environment that closely resembles production but is not production. Before go-live, you need to verify that every integration works correctly in the actual production environment. Configuration differences between environments, credential differences, and network routing differences between staging and production can cause integrations that worked perfectly in staging to fail in production.

Data Validation

Your data migration should be complete and verified before go-live. The specific checks depend on your organization, but a comprehensive data validation covers:

Master data completeness. Verify that all active customers, suppliers, employees, items, and locations have been migrated and that mandatory fields are populated.

Open transaction accuracy. Spot-check open purchase orders, sales orders, and customer invoices against the source system. Verify that quantities, prices, and dates match.

Financial balance reconciliation. Confirm that accounts receivable and accounts payable balances in the new ERP match the final exported balances from the legacy system.

Inventory on-hand accuracy. If you are migrating inventory records, confirm that on-hand quantities in the new system match a physical count or the legacy system’s final state.

Chart of accounts and opening balances. Verify that the chart of accounts is correctly structured and that opening balances match the prior-period close in your legacy system.

User Access and Readiness

A technically perfect system is useless if the people who need to use it cannot access it or do not know how.

Access Verification

Every user who will need to work in the new system on day one should have their account tested before go-live. This means:

• Confirming the user can log in
• Confirming the user’s roles and permissions give them access to the functions they need
• Confirming the user cannot access functions they should not have (segregation of duties)

Running a structured access review with managers from each department — asking them to confirm that their team members’ access looks correct — is the most practical approach. This also surfaces any access provisioning errors before they affect live work.

Training Completion

Verify that every user who needs to perform transactions in the system has completed training. For most implementations, this means tracking training completion by role and chasing completions that are outstanding.

Users who go into go-live day without training create extra support burden and are more likely to make errors that require correction. Even a brief one-hour session on the most critical processes is better than no preparation.

Parallel Run vs. Hard Cutover

Before go-live, you need to decide whether to run both the old and new systems simultaneously for a period, or to cut over entirely.

Parallel Run

In a parallel run, your team processes transactions in both systems for a defined period — typically two to four weeks. You compare the outputs to verify the new system is producing correct results before you decommission the old one.

Advantages: Provides a safety net. If the new system has errors, you have the old system as a fallback and can catch problems before they affect operations.

Disadvantages: Doubles the workload on your team during the parallel period. Can extend longer than planned if teams want to continue using the old system because it feels safer. Creates confusion about which system is the “true” record.

Hard Cutover

In a hard cutover, you migrate data on a defined date and go live exclusively on the new system. The old system becomes read-only or is decommissioned.

Advantages: Forces complete adoption of the new system. Eliminates the dual-processing burden. Creates a clear before-and-after.

Disadvantages: Higher risk if problems surface after cutover. Requires very high confidence in testing and readiness before committing.

The right choice depends on how much risk your organization can absorb. For most mid-market implementations, a well-tested system with a solid go/no-go process can proceed with a hard cutover. High-complexity implementations with extensive integrations or a history of data quality problems benefit from a parallel period.

Go/No-Go Decision Criteria

The go/no-go decision — whether to proceed with go-live as scheduled or delay — should be made against defined criteria, not intuition. Common go/no-go criteria include:

• All high and critical defects from user acceptance testing are resolved
• Data migration validation has passed with no outstanding reconciliation items
• All go-live users have confirmed access
• Training completion meets a defined threshold (e.g., 90% of required users trained)
• All priority-one integrations are tested and passing
• Rollback plan is documented and the team is prepared to execute it

If any of these criteria are not met at the scheduled go/no-go meeting, the decision to delay should be on the table. Proceeding when critical criteria are unmet is the most common way a go-live becomes a crisis.

What to Do in the First 30 Days After Go-Live

Going live is not the finish line — it is the start of a stabilization period. The first thirty days are often the most demanding period of an ERP project.

Days 1–7: Immediate Stabilization

• Assign dedicated partner support resources to be available immediately for go-live issues
• Set up a clear escalation path for critical issues (system-down, financial errors, integration failures)
• Run daily stand-up meetings with key process owners to surface and prioritize issues
• Document and triage every issue that surfaces — separate minor usability questions from critical functional errors
• Monitor integration health continuously for the first week

Days 8–30: Process Stabilization

• Identify recurring user errors and address them with targeted re-training rather than system changes
• Review any transaction errors that occurred in week one and correct them in the system
• Complete any data cleanup items that were deferred from the pre-go-live period
• Validate that month-end or period-end processes work correctly
• Formally close the go-live support period with a lessons-learned review

Ongoing: Transition to Business-As-Usual Support

After thirty days, most organizations transition from intensive go-live support to a regular support model. This typically involves:

• An internal help desk or power user network for first-line user questions
• A defined process for submitting enhancement requests to the partner
• A schedule for addressing non-critical defects found after go-live
• A plan for training new employees as they join

Frequently Asked Questions

When should the go/no-go decision be made? The formal go/no-go meeting should be held at least five business days before the scheduled go-live date. This gives enough time to resolve outstanding items if the decision is a conditional go, or to communicate a delay to affected stakeholders without the delay being discovered on launch day.

What is the most common reason for ERP go-live delays? The most common reasons are unresolved data migration issues and outstanding user acceptance testing defects. Both of these trace back to starting the validation work too late in the project. Starting data validation and formal UAT at least four to six weeks before the scheduled go-live gives time to address problems without delaying the date.

How long should we plan for partner support after go-live? Standard post-go-live hypercare support from an implementation partner typically runs two to four weeks. Complex implementations, high-volume operations, or integrations with significant variability may justify a longer hypercare period. Define this expectation in the implementation contract before the project begins.

What happens if we discover a critical error after we have already gone live? Having a documented rollback plan is essential, but rolling back a live production system after transactions have been entered is complex and sometimes not feasible. In most cases, the response is to engage the partner immediately for emergency support, document all affected transactions, and correct them in the new system. This is why thorough pre-go-live testing matters — the cost of correcting errors post-go-live is significantly higher than the cost of finding and fixing them during testing.