ERP Go-Live Checklist: 50 Things to Do Before Your System Launches

Most ERP go-live failures are not caused by technical problems. They are caused by data that was not validated, users who were not trained, and decisions that were deferred to go-live week because no one wanted to raise them earlier.

ERP teams often spend so much effort on configuration and testing that go-live readiness — the operational preparation — gets compressed into the last two weeks. The configuration was meticulous. The training was skipped because “people will figure it out.” The data migration validation was partial because there was not enough time.

This checklist covers every go-live preparation category: data, testing, training, IT infrastructure, communications, and hypercare planning — with go/no-go criteria for each phase.

Key Takeaways

Go-live day should be scheduled for a Friday evening or Saturday morning to maximize the recovery window before the business week starts.

A mock go-live (dress rehearsal) should be run one to two weeks before the actual go-live — it reveals problems while there is still time to fix them.

Data reconciliation to the penny — GL balances, AP/AR, inventory quantities — is the most critical pre-go-live task.

Thirty percent of go-live issues surface in the first 48 hours after launch; hypercare must start on Day 1, not when problems are escalated.

8 Weeks Before Go-Live

Final UAT Sign-Off

All UAT test scenarios have been executed and documented
All blocking issues have been resolved (not just logged)
Non-blocking issues have been categorized and assigned to a post-go-live punch list
Each business unit lead has signed the UAT sign-off form confirming their scenarios passed
Go-live blockers list is empty or contains only documented accepted risks

Go/no-go gate: UAT cannot be signed off with any unresolved blocking issue. Partial sign-off — “mostly done, we’ll fix the rest after go-live” — is not acceptable. Unresolved blockers at go-live become production problems.

Data Migration Dress Rehearsal

At least one full test migration has been completed against a production-equivalent environment
Test migration results have been reconciled against source system data
Error rates from the test migration are below 1% for critical data domains
Data cleansing is complete or has a defined completion date before go-live

Training Plan Completion

Training schedule has been published and communicated to all users
Role-based training curriculum has been defined (what each role needs to know)
Training environment (sandbox) is available with representative data
Training completion tracking is in place

Go-Live Date Confirmation

Go-live date has been confirmed by all stakeholders: project sponsor, IT, business leads, and vendor
Go-live date avoids peak business periods (month-end, quarter-end, year-end, peak seasons)
IT maintenance windows and vendor support availability have been confirmed for go-live weekend
Key vendor support contacts for go-live weekend have been identified and tested

4 Weeks Before Go-Live

Final Data Cleansing and Freeze Dates

Data freeze date has been set: after this date, no changes to legacy systems without project team notification
Outstanding data cleansing items have been assigned owners and completion dates
Customer master, vendor master, and inventory master data have been approved by business owners
Historical data archival strategy has been confirmed (what does not migrate, where does it go)

Integration Testing Sign-Off

Every integration has been tested in the production environment with production-equivalent data volumes
Integration error handling has been tested (what happens when the integration target is unavailable)
Integration SLAs have been confirmed (how quickly does data sync? what is the acceptable lag?)
Each integration owner has signed off on test results

Go/no-go gate: Untested integrations in a production environment are go-live blockers. Do not go live with integrations that have only been tested in sandbox.

Third-Party Vendor Notifications

EDI trading partners have been notified of the cutover date and any expected interruption window
Shipping carriers and 3PL partners have been notified
Payment processors or banking partners have been notified of system changes
Major customers with electronic ordering or invoicing connections have been informed

Cutover Plan Finalized

Cutover plan document is complete: step-by-step sequence of activities from legacy system shutdown to new system go-live
Each step has a named owner, estimated time, and verification criteria
Total cutover window time has been estimated and fits within the available window
All cutover resources have confirmed availability for the go-live weekend

2 Weeks Before Go-Live

User Training Completion Verification

Training completion rates by department have been pulled and reviewed
Departments with <80% completion have a plan to train remaining users before go-live
Super-user certification has been completed for each department champion
Quick reference guides and job aids are available for all roles

Helpdesk and Support Escalation Setup

Internal helpdesk protocol for go-live week has been defined: who handles what level of issue
Vendor hypercare support has been confirmed: hours of availability, contact names, SLA commitments
Escalation path is documented: internal level 1 -> super-user -> IT -> vendor
Issue tracking tool for go-live period has been set up and communicated

Go-Live Communication Sent to Staff and Customers

All employees who will use the new system have received communication about the go-live date and what to expect
Any customers or vendors who will notice a change (new invoicing format, new portal, changed EDI) have been notified
Internal FAQ has been published for common questions
Department managers have been briefed on their role during go-live week

Rollback Decision Criteria Defined

Criteria for invoking a rollback to the legacy system have been documented and agreed upon
Maximum acceptable downtime before rollback is triggered has been defined
Rollback procedure has been tested (not just documented)
Data that will be lost if rollback is invoked has been identified and communicated to the project sponsor

1 Week Before Go-Live — Dress Rehearsal

Mock Go-Live Execution

Run a complete simulation of the go-live weekend, including:

Cut data entry in the test environment as of the mock cutover date
Execute the migration against the test environment using the final migration scripts
Validate migrated data against source system
Perform first transactions in the new system to verify everything works post-migration
Document time required for each step against the plan

A mock go-live reveals timing problems — the cutover takes six hours when you planned four — while there is still time to adjust the plan or extend the cutover window.

Data Migration Trial Run

Final migration scripts have been run against a copy of production data
Reconciliation reports have been produced and reviewed
Any remaining data quality issues have been resolved or accepted as managed exceptions

System Performance Baseline

System performance has been tested at expected go-live day transaction volumes
Performance baselines have been established for key transaction types (order entry, report generation, inventory lookup)
Performance alerts have been configured to flag degradation during go-live week

Paul W., IT Director at a $35M plastics manufacturer: His team ran a mock go-live two weeks before the real date. The mock migration took nine hours instead of the planned six. They found two data transformation scripts that were running sequentially rather than in parallel. The fix took four hours. Without the mock, they would have discovered this at 3 AM during the real go-live weekend with no time to fix it. “The dress rehearsal was the most valuable thing we did. It was not exciting. But it saved the project.”

Go-Live Day and Weekend

War Room Setup

Establish a go-live war room — a central coordination point for the go-live weekend:

War room (physical or virtual) has been set up with access for all go-live team members
Communication channel (Slack, Teams, dedicated phone line) for real-time status updates
Issue log is open and accessible to all war room participants
Decision authority is clear: who can make scope/rollback/delay decisions?
Vendor support is connected to the war room

Sequence of Go-Live Activities

The standard go-live sequence:

Notify all users that the legacy system is now read-only (no new transactions)
Run final data extraction from legacy system
Execute final data migration to new ERP
Run reconciliation reports
Enable new system for all users (or by department, if phased)
First transaction validation by each department

Each step has an owner and a target completion time
Go-ahead for each step requires explicit confirmation from the previous step owner

First Transaction Validation

Within the first two hours of go-live, each department should complete a validation transaction:

Finance: post a manual journal entry and confirm it appears in the GL
AP: enter a vendor invoice and confirm three-way match with a PO and receipt
Inventory: receive a PO and confirm quantity and cost updates
Order management: enter a test sales order and confirm inventory reservation
Integrations: confirm that data is flowing from connected systems

Data Reconciliation Checkpoints

GL opening balances in the new system match the closing balances from the legacy system
AR aging total in the new system matches the AR aging total from legacy
AP aging total in the new system matches the AP aging total from legacy
Inventory total value in the new system matches the physical count and legacy system value

Any unreconciled discrepancy above your materiality threshold is a go-live blocker.

Go/No-Go Decision Criteria

What Delays Go-Live

The decision to delay go-live is the right decision in specific situations:

Data reconciliation gaps that cannot be explained or resolved before business hours
A blocking UAT issue discovered during go-live weekend validation
An integration failure that affects core business processes (order entry, payment processing)
Key user populations that have not completed training

How to Make the Delay Call

The project sponsor makes the delay decision, with input from the project manager and department leads. The decision criteria should be pre-defined (see rollback criteria above) so the call is based on facts, not pressure.

A 24–48 hour delay to resolve a blocking issue is far less costly than a live launch with a broken process that affects every transaction for weeks.

Hypercare: First 30 Days Post-Go-Live

Daily Stand-Ups

Run a 15-minute daily stand-up for the first two weeks post-go-live:

What issues are open?
What was resolved yesterday?
What decisions need to be made today?
Any early warning signs of systemic problems?

Escalation Protocol

Issues are logged in a central tracker with severity classifications
Response SLAs are defined by severity (critical: 2 hours; high: 4 hours; medium: 24 hours)
Vendor support is engaged for issues that cannot be resolved internally
Weekly status report to the project sponsor

Key Metrics to Monitor

Track these weekly in the first 30 days:

Transaction error rate (percentage of transactions requiring manual correction)
Support ticket volume by category (training issues, data issues, configuration issues)
Integration sync error rates
User activity levels (are users actually using the system, or reverting to old tools?)

Rachel B., COO at a $28M specialty distributor: Her team went live on a Saturday. By Monday morning, they had 47 open issues in the tracker. By end of week one, 38 were resolved. The nine remaining were categorized: six were configuration changes scheduled for the following week; three were training gaps addressed by super-user sessions. “Having a structured issue log from Day 1 meant nothing fell through the cracks. The ones we couldn’t fix immediately were tracked, not forgotten.”

What to Do When Something Goes Wrong at Go-Live

Not every go-live problem is a rollback trigger. The decision framework:

Isolate the impact. Is this problem affecting one department or all users? One transaction type or all transactions? A localized problem may be workable while a resolution is implemented.

Quantify the risk. Can the business operate with the problem present? If orders can still be entered and inventory can still be received, the business can function while the fix is applied. If financial transactions cannot process, that is a harder blocker.

Assess the fix timeline. Is this a configuration change that takes four hours, or a development fix that takes two weeks? A four-hour fix argues for powering through. A two-week fix may argue for rollback.

Communicate clearly. The go-live team, the project sponsor, and affected departments need real-time information. Information vacuums create panic. Clear, factual updates — “we have a problem with [specific function], the team is working on it, we will have an update in two hours” — maintain confidence.

Conclusion

Go-live readiness is not an IT milestone. It is a business readiness milestone. The data is right. The users are trained. The processes have been tested. The support is in place. When all of those are true, go-live succeeds.

The companies that have the smoothest go-lives are not the ones that got lucky — they are the ones that ran the mock, validated the data, and defined their go/no-go criteria before the pressure of go-live weekend made those decisions harder.

See Netodin ERP Implementation Support Get a Go-Live Readiness Review

Frequently Asked Questions

When is the best time to go live on ERP? A Friday evening or Saturday morning start maximizes the recovery window — you have 48+ hours before the business week starts. Avoid go-lives at fiscal year-end, during peak selling seasons, or immediately before a major customer deadline. The timing should be chosen for operational risk minimization, not vendor schedule convenience.

What is a mock go-live and why does it matter? A mock go-live is a complete rehearsal of the go-live weekend, typically run one to two weeks before the actual date. It uses the final migration scripts against a copy of production data, validates that the cutover sequence works within the planned time window, and surfaces problems while there is still time to fix them. Teams that skip the mock go-live frequently discover timing problems or data issues on the real go-live weekend when they cannot be easily fixed.

How long should hypercare last? Standard hypercare is 30 days of elevated support. Complex implementations or high-volume environments may need 60–90 days. Hypercare ends when the issue rate drops to a stable, manageable level and the internal support team can handle routine issues without vendor escalation.

What if our key team members are unavailable for go-live weekend? Reschedule. A go-live without the people who know the system and the business is a risk that should not be accepted. If the project manager, the finance lead, and the operations lead are not available, the go-live should be delayed until they are.

ERP Go-Live Checklist: What to Do Before Launch | Netodin