What to prepare before an ERP go-live
The documents, people, and decisions a business should line up before SAP Business One or another ERP goes live.
Name the people who do the work
Go-live fails quietly when only managers attend the workshops. Accounts, sales, stores, and production each need someone who enters today’s transactions and can say when a screen does not match the real step.
Agree who approves item names, tax setup, price lists, and the opening balances. Those decisions take longer than the software installation.
Clean a small set of master data
Start with customers you still sell to, suppliers you still buy from, and items you still stock. Duplicate names and missing units will show up on the first invoice.
Bring opening stock, open sales orders, open purchase orders, and outstanding customer and supplier balances. Sample reports from the current system help the team check that the new records match.
Rehearse one full day
Before the switch, run a normal day on test data: raise a purchase, receive stock, make a sale, collect a payment, and print the report a manager checks each morning.
Train the people who will repeat that day. Support after go-live should cover the same transactions, not a separate list of features nobody uses.
Worked example
A plant that went live on a Monday and closed the month on time
A food processor set its go-live for the first Monday of a quarter. Three weeks earlier, the finance lead froze new item codes and customer records in the old system, so the migration templates stopped changing. Two weeks earlier, the team ran a full trial load and posted a week of real transactions in the test company; the differences found were units of measure on a dozen items and two tax codes.
The weekend before go-live, stock was counted by warehouse and batch, opening balances were loaded, and the reconciliation was signed off by the finance lead before anyone posted a live document. The first month closed four days after period-end, which was faster than the old system because nothing had to be reconstructed.
What made the difference was not the software. It was a coordinator with authority, frozen master data, one rehearsed cutover, and users who had already posted their own transactions in test.
Checklist before you decide
- A named project coordinator who can make decisions without a committee
- Master data frozen in the old system from an agreed date
- Item, customer, and supplier lists cleaned of duplicates and dead records
- A trial balance and ageing reports as at the planned cutover date
- Opening stock counted by warehouse and, where used, by batch
- Every document layout you issue, approved in the new system
- Users who have posted their own transactions in the test company
- A cutover weekend plan with owners for each step and a sign-off
- Support arrangements for the first weeks agreed in writing
Questions we hear
How long before go-live should we freeze master data?
Two to three weeks is typical. New records after the freeze are logged and added to the cutover load so nothing is lost.
Should we run both systems in parallel?
Rarely for the whole business; it doubles the work and hides problems. A short parallel run for one process, such as invoicing, for one week is usually enough.
What if the stock count does not match the books?
Investigate the large differences, post the adjustment in the old system with sign-off, and load the counted figures. Going live with known differences is better than going live with unknown ones.