What to prepare before migrating to a new accounting system

Migration projects rarely fail because of the software. They fail because the data was worse than expected, the chart of accounts was copied rather than designed, opening balances were never properly agreed, and the business discovered during cut-over that nobody had decided who would do what. All four are preventable with preparation.

Our ERP Readiness Checklist turns this article into a working document. What follows is the reasoning behind it.

Establish the true starting position

Before migrating anything, know what is true today. Reconcile every bank account, confirm receivables and payables balances to source documents, count stock, and agree the position to the last reliable accounts. If the current records are unreliable, migrating them transfers the problem into a new system with a fresh coat of paint — and makes it harder to detect.

This step is unglamorous and non-negotiable. We have seen more migrations delayed here than anywhere else.

Clean the data before you move it

Customer and supplier lists accumulated over years typically contain duplicates, inactive records, missing tax details, inconsistent naming and obsolete entries. Item lists contain discontinued products, duplicate codes and wrong costing. Migrating all of it guarantees the new system is as unusable as the old one.

• De-duplicate customers and suppliers, and agree which record survives.
• Mark or remove inactive records rather than carrying them forward.
• Standardise naming so that reports group correctly.
• Confirm tax details for every active customer and supplier.
• Review the item list and remove what is no longer traded.
• Agree what history must move and what stays in the old system for reference.

On that last point: most businesses do not need ten years of transactions in the new system. Opening balances plus the current year is usually sufficient, with the old system retained read-only. Migrating unnecessary history adds cost, risk and noise for very little benefit.

Design the chart of accounts — do not copy it

The chart of accounts determines what you can report. Copying the default list, or the old structure, is the most common reason a new system fails to produce useful management accounts. Design it around the questions management asks: by branch, by project, by product line, by department. Use dimensions or cost centres for analysis rather than multiplying ledger codes, and keep the code list short enough that postings are consistent.

Document the mapping from the old structure to the new. You will need it during migration, during the first audit, and whenever someone asks why the numbers changed.

Agree opening balances properly

Opening balances are the foundation of everything that follows. Bank balances should agree to statements. Receivables and payables should agree to aged listings that reconcile to source documents. Stock should agree to a count. Tax balances should agree to filed positions. Each should be documented and signed off by the person responsible for the accounts.

Where the old records cannot support a balance, say so and agree a documented basis. An honest, documented opening position is far better than a precise-looking figure nobody can defend.

Configure controls, not just settings

A migration is the best opportunity to fix controls, because everything is being rebuilt anyway. Decide user roles and permissions, approval limits, period lock rules, who can post journals and who can change master data. Configure these before go-live rather than promising to do it later; later does not happen.

Plan the cut-over

A cut-over plan states what happens, when, and by whom: the last transaction date in the old system, when data is extracted, when opening balances are loaded, when the new system goes live, who handles transactions in the gap, and how outstanding items are dealt with. For most businesses a month-end or quarter-end cut-over is cleanest. For larger operations, parallel running for one or two periods is worth the effort because it allows the numbers to be compared before the old system is retired.

Test the awkward cases

User acceptance testing should use real scenarios, including the difficult ones: part payments, credit notes, returns, multi-currency, inter-company transactions, discounts, deposits and reversals. Test with the people who will do the work, not only with the finance manager. If a scenario cannot be handled, discover it in testing rather than in week one of live operation.

Train by role and write it down

A single group training session covering every feature helps nobody. Train the warehouse user on stock movements, the sales team on quotations and orders, the finance team on the close. Provide written procedures each role keeps. And train at least two people on everything critical, because single-person dependency is how a business loses control of its own system.

Plan the first month-end

The first close on a new system always raises questions. Agree in advance who answers them, what the close calendar looks like, and what will be reviewed afterwards. Budget time for it. A migration that ends at go-live without supporting the first close usually needs a second project to finish it.