Switching ERP systems without losing a beat

When an ERP switch goes badly, the new software is rarely the main reason. The move itself was rushed: dirty data carried across, totals nobody tied out, and a go-live date picked for convenience. This is a plan for a cutover your customers never notice.

Write down what "done" means

Before anyone exports a file, agree on what has to be true on the first morning in the new system. Keep it to one page, and put a name next to each line.

• Every customer's open balance matches the old system to the cent.
• On-hand quantity by item, lot and warehouse matches the final count.
• Every open purchase order and unpaid supplier bill is there.
• A customer's usual order prices the same as it did last week, unless you decided to change it.
• An order can be entered, picked, delivered, invoiced and paid from start to finish.

If nobody owns the price check, nobody does it. The same goes for every other line.

Step 1: clean before you move

You do not migrate junk. Every bad record you carry over becomes a problem someone has to solve in your first, busiest week on the new system. Work through the master data first:

• Customers. Merge duplicates, retire accounts that stopped ordering long ago, standardise ship-to addresses, and confirm payment terms and credit limits.
• Items. Flag discontinued SKUs, make units of measure consistent (case, each, pound) and mark every catch-weight item, so it is priced and invoiced by weight from day one.
• Open AR and AP. Reconcile both to the general ledger. Collect, write off or agree a plan for old balances, so you are not migrating disputes.
• Inventory. Count it. A full count, or a recent round of cycle counts that covers every location, gives you an opening balance you can trust.
• Prices and deals. List every customer price, tier and deal still in use. Expired deals should not come across.

Step 2: decide what history comes across

Not everything has to move. Bring what the new system needs to run and to report, and leave the rest in a read-only archive.

For sales history, try to bring at least a full year, so seasonal items have something to compare against.

Step 3: build and rehearse the load

Set up the new system while the old one keeps running: chart of accounts, tax settings, payment terms, credit limits, price lists, warehouses, users and permissions. Then rehearse the data load on a test copy, more than once.

A rehearsal only helps if you check the result. After each trial load, compare:

• Total AR and the number of open invoices, by customer.
• Total AP and open bills, by supplier.
• On-hand quantity and value, by item and warehouse.
• Prices, by pricing a sample of real customer orders in both systems.

Fix the mapping, not the numbers. When a total is off, find the rule that caused it and correct it in the load. Then the next rehearsal, and the final load, come out right on their own.

Step 4: run in parallel

Before go-live, put real days through both systems and compare the results while the old system is still the one you trust. This is where you find the invoice that rounds differently, the tax code mapped wrong, or the GL account that collects postings it should not.

A parallel run means double entry, so keep it focused. Choose real transactions that cover your awkward cases:

• A catch-weight order invoiced on the shipped weight.
• A partial delivery, and a return that becomes a credit.
• A customer on a deal or a special price.
• A supplier bill with freight, matched to its receipt.
• A customer payment that covers several invoices.

If those come out the same, the easy cases will too. If you can, carry the parallel run through a month-end, so you see the close work before you depend on it.

Step 5: the cutover weekend

1. Freeze. Once the last trucks are loaded, stop entering receipts and adjustments in the old system. Ship what is already queued.
2. Snapshot. Print or export the final reports: open invoices, AR by customer, open POs, unpaid bills and on-hand by lot.
3. Count. Count the warehouse if you can, or at least the fast movers and the high-value items.
4. Load and tie out. Load the final data and compare every total to the snapshot. Money should tie to the cent. If it does not, stop and fix it before Monday.
5. Practise. Have the order desk enter a few of Monday's real orders before the phones start.
6. Go live. The old system becomes read-only. Keep it available for lookups.

The first weeks

Expect the first days to be slower. People are learning where things are, and every question costs a minute. Plan for it rather than hoping it will not happen:

• Put a named helper on each shift: at the order desk, in the warehouse and at dispatch.
• Keep one list of issues, with who raised each one and who is fixing it. Review it every afternoon.
• Check the money daily: invoice totals, payments applied and the AR total. A small error is cheap on day two and expensive at month-end.
• Ask pickers and drivers what slowed them down. Their problems do not show up in reports.

Five mistakes that sink a migration

1. Migrating everything. Bring what you use. Archive the rest.
2. Thin training. Train people on their own jobs with your own items and customers, not on a generic demo.
3. No way back. Keep the old system intact, and decide in advance what you would do if go-live goes badly.
4. Going live in your busy season. Pick your slowest stretch. A distributor that peaks before the holidays should not cut over in November.
5. Customising everything on day one. Get to "as good as the old system" first, then make it better.

If you have not chosen the new system yet, start with how to evaluate an ERP demo.

How a switch to APFoodz works

APFoodz brings your data across for you and runs alongside your current system before you switch.