Go-live night — six steps, and the point of no return

Go-live is written into every plan as a date. It behaves as a window — usually about two days, from the hour the old system stops recording to the hour the last user is working normally in the new one.

Treating it as a date is what produces the improvised night. Treating it as a window means somebody has decided in advance what happens in each hour of it, including the hours where something goes wrong.

Six things that must be true before you open the window

Not a wish list. Any one of them missing is a reason to move the date, and moving the date is far cheaper than the alternative.

1. UAT signed against your own scenarios, not the vendor’s script. A test that follows the vendor’s happy path proves the demo worked.

2. Opening balances reconciled to the penny. The trial balance in the new system agrees exactly with the last approved trial balance in the old one. How those balances are built is set out in data migration.

3. Every user has executed their own document at least once. Not watched a training session — actually raised the purchase order, actually confirmed the receipt.

4. Permissions verified by each user logging in as themselves. Permissions tested by an administrator are not permissions tested.

5. A real invoice printed in Arabic, in its final format, on the paper it will actually be printed on.

6. A rollback plan written down, before the night rather than during it.

Choosing the date

The first day of an accounting period, and preferably the first day of the fiscal year. Any other choice means a period split across two systems, and every report for that period then has to be assembled by hand from two sources that do not agree.

Never during a seasonal peak. The month your business is busiest is the month it has the least tolerance for a slow screen and no capacity at all for a wrong one.

The night itself, in order

1. Stop recording in the old system at an announced hour. Announced beforehand and in writing, because the failure mode here is one department that kept entering documents for another three hours.

2. Extract the final balances. Trial balance, accounts receivable ageing, stock valuation. Print them and keep them. These are the numbers everything after tonight is checked against.

3. Physically count the stock if you can. This is the step that gets dropped when the night runs late, and it is the one that costs the most later: without it you have inherited the old system’s stock error and can no longer tell it from a new one.

4. Load the balances into the new system.

5. Reconcile and sign. This is the point of no return. Somebody — the accountant, by name — compares the loaded balances against the printouts from step 2 and signs. Nobody gets access to the system before that signature. A user who starts transacting on unreconciled balances has made the reconciliation impossible to complete.

6. Open the system to users, and have one test document of each type raised and posted before the working day begins.

The rollback plan needs three things in writing

Everyone agrees a rollback plan is necessary. Almost nobody writes one that can actually be executed, because a plan that says “revert to the old system if there are problems” decides nothing at three in the morning.

What triggers it. A stated criterion, not a judgement: balances that will not reconcile after two attempts, or a load that has not completed by a named hour.

Who owns the decision. One person, present that night, whose call it is. Not a committee, and not the person running the load.

Until what hour it remains available. After a certain point the old system’s data is stale and reverting costs more than continuing. Know that hour before the night starts, because after it the plan is no longer rollback — it is repair.

The first week is more dangerous than the night

The night has everyone’s attention. The following week does not, and that is where a go-live is actually lost.

Be among the users, not in a meeting room. Support that requires a ticket to be raised gets no tickets and a large amount of quiet workaround.

One logged channel for problems. Not a corridor conversation and not four WhatsApp groups. If a problem is not written down, it is not counted, and the same one is solved four times.

No customisation in week one. Every request logged, none built. Roughly half of them stop being requested after two weeks, once the user has found the standard way of doing the thing. Building in week one means maintaining, at every upgrade for the life of the system, a feature nobody would have asked for in week three.

The only credible sign of success

Not that the system opened. Not that nobody complained on day one.

A full first month closed on the new system alone, with the statements matching. Bank reconciled, sub-ledgers agreeing with their control accounts, and no parallel spreadsheet anywhere in the finance department. What that close involves is in the ledger and the close, and the stock valuation that feeds it is in inventory and costing.

Until that month is closed, a company running two systems in parallel has not gone live. It has doubled its workload and called it caution.

Where to go from here

The full reading order, from what an ERP is through to the four cycles, is on the learn ERP page. What each product gives you for cutover and the first month — import tooling, period locking, audit trail — is set out in the systems comparison.