ERP Implementation Guide: What to Do Before You Go Live

The Go-Live Moment Nobody Talks About

There's a moment in every ERP implementation that nobody prepares for properly. It's the morning of go-live, the system is live, and the operations team is staring at something that looks nothing like what they tested. Panic sets in. Workarounds proliferate. Spreadsheets reappear. Six months later, half the organization has given up on the ERP and reverted to the old way.

This isn't a technology failure. It's a preparation failure. The implementation team built the system correctly — they just didn't prepare the organization to actually use it.

This guide is about everything that needs to happen before go-live. Not the technical configuration (that's table stakes), but the organizational, data, and process work that determines whether the go-live is a success or a very expensive mistake.

Phase 1: Define Success Before You Start

This sounds obvious. It is not done on most projects.

Before any configuration begins, you need documented, specific answers to these questions:

What does success look like in 90 days? Not vague aspirations like "better visibility" — specific, measurable outcomes. "Inventory accuracy above 98%." "Month-end close in five business days instead of twelve." "Zero manual reconciliation between the warehouse and accounting."

Who owns each functional area? ERP implementations fail when nobody clearly owns a module. Finance owns the GL. Operations owns inventory. HR owns the employee record. Document ownership and make it explicit.

What are the must-have requirements vs. nice-to-haves? Write this down. You will be tempted to solve every problem during implementation, and you will kill the project trying. Identify the 20 things the system must do at go-live. Everything else is phase two.

What is the rollback plan? Nobody wants to think about this. You should think about it anyway. What do you do if go-live fails catastrophically? How long can you run in parallel before you must commit? What's the decision criteria for rollback? Having this plan doesn't mean you'll use it — but it forces a level of rigor that prevents avoidable disasters.

Phase 2: Audit Your Data Before You Touch the System

Data migration is the silent killer of ERP implementations. Teams spend months configuring workflows and spend three weeks on data, which is exactly backwards.

Your ERP is only as good as the data you put in it. And the data you're pulling from your current systems is probably a mess — not because anyone was careless, but because data degrades naturally over time without a system enforcing consistency.

Start with a data audit. For each major data category (customers, vendors, items, chart of accounts, open transactions), answer:

What is the current source of truth?
What percentage of records are complete and accurate?
What duplicates exist?
What obsolete records are there (vendors you haven't used in five years, discontinued items)?
What data exists in formats the new system can't ingest?

This audit takes time. Do not skip it. The companies that skip it spend the first three months of go-live dealing with data quality issues that could have been resolved before the system launched.

Define data governance before migration. Who can create a new vendor record? What fields are required? What naming conventions apply? What approval workflow exists for changes to master data? If you don't define this before go-live, you'll recreate the data chaos in your new system.

Build and test your migration scripts. This isn't a one-time task. Run the migration against a development environment, verify the output, clean the data, run it again. Most teams run three to five migration cycles before the data quality is acceptable for go-live.

Define cutover data. What open transactions migrate to the new system? What historical data comes over, and how much? What can stay in the old system for read-only reference? The cutover data definition is one of the most complex parts of implementation — plan for it accordingly.

Phase 3: Map Your Processes Before You Configure

ERP systems enforce process. If you haven't defined your process, the ERP will enforce whatever you built during configuration — including every gap, inconsistency, and assumption.

Document your current-state process flows. For each major workflow — a purchase order from request to payment, an inventory receipt from dock to shelf, a sales order from entry to cash — document how it actually works today. Not how the procedure manual says it works. How it actually works, including the workarounds and exception handling.

Identify process gaps and conflicts. The current-state documentation will surface gaps you didn't know existed. Two people think they're responsible for the same approval. The warehouse team has a workaround for receiving partial orders that nobody in accounting knows about. These gaps need resolution before they're baked into the ERP configuration.

Design your future-state process. How will each workflow run in the new system? This is where you make deliberate choices about what changes versus what stays the same. Not every process needs to change — only the ones that are genuinely broken or that the ERP genuinely improves.

Get process sign-off from process owners. Each functional area lead needs to explicitly sign off on the process design for their area before configuration starts. This creates accountability and prevents "that's not how we do it" surprises at UAT.

Phase 4: Configuration and UAT Done Right

Configure to your signed-off processes. This seems obvious, but drift happens. A consultant defaults to the system's standard workflow instead of your custom requirement. A module gets configured by someone who wasn't in the process design sessions. Regular configuration review against your process documentation prevents this.

UAT is not a formality. User Acceptance Testing is the moment you find out whether the system you built matches the process you designed. It works only if you take it seriously.

Real UAT requirements:

Actual end users, not just the implementation team
Real business scenarios, not demo scripts provided by the vendor
End-to-end transaction testing, not module-by-module feature testing
Documented test results, not verbal sign-off
Formal defect tracking, not email threads
Enough time to fix and retest — not a sign-off on a broken system because the go-live date is fixed

Schedule at least three weeks for UAT on a mid-complexity implementation. Build in one round of fixes and retest before sign-off.

Phase 5: Training That Sticks

ERP training is almost universally done wrong. The standard approach: bring everyone into a conference room, run through the system for a day, hand out a user guide, declare training complete. Two weeks later, nobody remembers anything and everyone is calling the help desk.

Training works when it's:

Role-based, not system-based. Train people on what they do in the system, not on every feature in their module. A warehouse receiver needs to know how to process an inventory receipt. They don't need to know how to configure a reorder point.

Hands-on in the training environment. People learn by doing. Every training session should involve trainees actually completing transactions in a training environment with real-looking data.

Timed correctly. Training done three months before go-live gets forgotten. Train within two weeks of go-live when possible. The closer to go-live, the better retention.

Supplemented with job aids. One-page reference cards for the most common tasks, accessible at the desk. Screenshots of the exact screens. Step-by-step instructions written for the actual user, not for a generic ERP user.

Followed up with hypercare. The first two weeks after go-live are critical. Have dedicated support resources — either your implementation partner or your internal super-users — available to answer questions and resolve issues immediately. Slow response during hypercare destroys confidence in the system.

Phase 6: The Go-Live Plan

A go-live is a project within a project. You need a documented plan for every action that happens in the 48-72 hours around cutover.

Your go-live plan should include:

Exact cutover sequence and timeline (hour by hour)
Who is responsible for each step
How you verify each step completed successfully
What the rollback trigger conditions are and who can call rollback
Communication plan — who gets notified at what milestones
Escalation path for critical issues
Post-go-live monitoring plan for the first 30 days

Run a dry run of the cutover process. Not a full data migration, but a walkthrough of every step in the sequence to identify gaps before you're doing it live.

The Metric That Actually Matters

The measure of a successful ERP implementation isn't go-live day. It's 90 days after go-live. Are people actually using the system? Is data quality improving? Are the manual workarounds shrinking?

The systems that succeed at 90 days are the ones where the preparation was thorough enough that the system matched what people expected, and the training was good enough that people could actually use it. Everything else is solvable with time — but only if the foundation is solid.

If you're planning an ERP implementation and want to talk through the preparation sequence — or if you're mid-implementation and starting to feel the warning signs — schedule time at calendly.com/jamesrossjr. These problems are much easier to solve before go-live than after.