Most accounting migrations go wrong in the same three ways: they happen mid period, the opening balances are not verified, and the historical detail turns out to be unreachable when the auditors ask for it. All three are avoidable with a plan.
When to switch
The start of a financial year, first choice. The start of a VAT period, acceptable. Any other time, avoid. Migrating mid period means producing one VAT201 from two systems, and every error we see in migration work traces back to that.
Give yourself six weeks between deciding and switching. Not because the work takes six weeks, but because the questions you have not thought of surface in week three.
What to move
Move balances, not history. Specifically:
- Trial balance as at the conversion date, agreeing to your last signed or reviewed set
- Open customer invoices with their original dates, so the age analysis is correct from day one
- Open supplier invoices, same
- Bank balances per account, reconciled to a statement
- Stock on hand with quantities and values, where you carry stock
- Fixed asset register with cost, accumulated depreciation and remaining life
- Customer and supplier master data, cleaned first
Do not attempt to move three years of transaction detail. It is slow, it is error prone, and the receiving system will not hold it in a shape that satisfies anyone. Keep the old system readable instead.
Keeping the old system readable
This is the step people skip and regret. SARS can request supporting documentation for five years, and your auditors will want prior year detail.
If the old system was desktop, keep a working installation on a machine that will still boot, plus the licence details. If it was cloud, export everything before you cancel, because access ends when billing does. Export the general ledger detail, the customer and supplier ledgers, the trial balances, and critically the transaction attachments if the system holds them.
Test that the export opens and is readable before you cancel the subscription. A twelve gigabyte archive that turns out to be in a proprietary format is not a record.
Proving the opening balances
After loading, run a trial balance in the new system as at the conversion date and place it next to the old one. They must agree line for line. Where they do not, find out why before you process a single transaction.
Then run the age analysis in both systems and agree the totals and the ageing buckets. An age analysis that agrees in total but not by bucket means invoice dates were loaded as the conversion date, which produces a wrong debtors report every month afterwards.
Have your accountant sign off the opening balances. It costs a couple of hours and it is what you produce if the position is ever questioned.
Run parallel for one period
Process one month in both systems. It is duplicated work and it is the only way to find the differences while they are still cheap to fix. Reconcile the two at the end of the month and only then decommission the old process.
Tell the people who need to know
Your accountant, before you start rather than after. Your auditors, if the year is under audit. Your bank, if statements feed the system. And your customers, if invoice numbering or bank details change, because a changed bank detail on an invoice is exactly the shape of a common fraud and your customers are right to query it.