ERP Go-Live: Test the Real Week Before You Switch

Most ERP testing passes. Then the first Monday arrives and the warehouse cannot keep up, customer service cannot find a price, and the report finance relies on shows a number nobody recognises. Nothing failed, because the tests were never shaped like the week that was about to happen.

A function test asks whether the system can create an order. The question that matters is whether a normal week, with its rush orders and corrections, can be done in the new system by the people who will do it.

Why testing gets squeezed

Testing comes last, so it absorbs every delay that came before it. Scenarios get written by the people who configured the system, run on clean data, one function at a time, with a consultant at the keyboard. Everything passes, and the handovers between departments, where most of the real work lives, are never tested. Exceptions get checked on their own, and speed is never tested at all.

On the Waterlogic Hungary project, the test plan covered the financial, operational and reporting workflows before go-live.

Pick the week

Do not invent a test week. Take one that already happened, or one that is about to, and use its documents as the script.

• Do not pick the quietest week you can find. The easiest week to test proves the least.
• Include a period end if one falls nearby. Month end is where migration shortcuts and report gaps surface together.
• Take the real documents and volumes. The actual orders, receipts, delivery notes, invoices and credit notes from that week, in the same numbers.

Write down what you expect before anyone starts: orders processed, time per invoice, what stock should look like at the end.

Force the exceptions through it

The test only pays off if the awkward cases are in it on purpose. Pull the ones that happen every week and put them in the same run:

• a partial delivery, with the remainder on a second shipment
• a customer who changes an order after picking has started
• a return and a credit note against an invoice from the previous month
• a price change mid week, plus a customer specific discount
• a rush order that jumps the planning queue
• a blocked or over-limit customer who needs releasing
• a supplier invoice that does not match the receipt
• one interface failure on each connection that matters

Let the key users add the cases a project team would not think of. If a case needs a workaround, it goes on the go/no-go list, not in a note for later.

Who runs it

Key users sit at their own keyboards, in their own roles and permissions, in one room or one call, so the handovers get tested too. The project team watches and fixes what breaks, but does not drive.

Three roles separate a test from a demonstration. A test lead from the business owns the week and decides when a scenario counts as passed. The key users per flow execute, and say out loud when they would have done something differently in the old system. The project team stays on standby to clear blocking defects and log the rest.

Run at real speed for two consecutive days at least, ideally a full week. Stopping for every small issue hides the time the team really loses.

What to measure

Correctness is the floor, not the score. Measure what you would also measure in the first week after go-live:

• orders and order lines processed per day, against the chosen week
• picks per person per shift, and time per pick
• time to create and post an invoice
• manual interventions: records rebuilt, data retyped, files exported to finish a task
• open items at the end of each day, and how many needed a second pass
• errors that stopped work, and how long each blocked a flow

Compare each number with the old system on the same week. A small gap you can explain is a training point. A large gap, or one nobody can explain, is a readiness problem.

Make the go/no-go concrete

The test week produces evidence, and it belongs in front of the people who decide. Fix the criteria before the run, then report against them:

• every critical flow completed a full cycle on migrated data, by the business team, without consultant hands on the keyboard
• throughput within an agreed margin of the old system, with a plan for the difference
• no open defect blocks a critical flow, and the rest is triaged with an owner and a date
• the exception list fully exercised, each case handled in the system or covered by a workaround someone owns
• data reconciled and signed off, on the checks set out in ERP Data Migration: Master Data Is a Business Job
• integrations held for the whole run, with no silent queue stops
• a fallback for the first days, in writing

ERP Data Migration: Master Data Is a Business Job

Move one person to make the call. A committee finds a reason to proceed. A named decision maker with the numbers in front of them, and the authority to move the date, is the only arrangement in which a no-go is possible.

Where hypercare fits

The weeks after cutover are a separate subject, with their own staffing, ticket flow and end point. What Happens After Go-Live sets out the hypercare model, who owns what in the first weeks and the criteria for moving to steady state. Go-Live Is Not the Goal covers why the switch-over is a milestone rather than the end. Settle that handover before the test week.

What Happens After Go-Live

Go-Live Is Not the Goal

A short checklist

1. Plan testing alongside configuration, not only at the end.
2. Choose a real week, with real documents and real volumes.
3. Write the expected result down before the run starts.
4. Force the weekly exceptions through it, where they really occur.
5. Let key users drive, with the project team on standby.
6. Run at least two consecutive days at real speed.
7. Measure throughput and stock accuracy against the old system.
8. Turn the numbers into a go or no-go with one named decider.

The bottom line

An ERP go-live is decided by whether the business can run a normal week in the new system, at a speed it can live with. Test that week properly, force the exceptions through it, measure what you would measure live, and let the numbers rather than the date make the call.