Accounting Software Migration: Keeping Your History Intact

Software changes usually stall at one question from the owner: what happens to our history? This article is for finance managers and accountants who want to migrate cleanly, without creating problems in a tax audit or losing the ability to compare with prior years.

Define the scope before anything else

Most stalled migrations begin with an unrealistic expectation: that everything must move. In practice your data has three layers, and each needs its own decision.

• Master data — chart of accounts, customers, suppliers, items, warehouses, employees, cost centres, projects. This must move.
• Balances — account balances, sub-ledger detail, stock quantities and values, open receivables and payables, employee service and leave balances. This must move.
• Historical transactions — prior-year journals, invoices and receipts. In most cases this should not move.

Migrating years of detail typically costs several times its value and is the main source of error. The standard answer is to keep the old system read-only for reference.

Timing

If a mid-year move is unavoidable, documentation matters even more: interim statements, the balance reconciliation and an explanation of document numbering continuity should stay in the file.

Step one: clean the master data

This is the highest-return stage of the whole project and the one most often skipped. Export to a spreadsheet from the old system and work there.

1. Merge duplicate counterparties using the national ID or economic code as the key, never the name — names are stored with inconsistent spacing.
2. Deactivate dormant parties with zero balances rather than migrating them.
3. Rationalise item codes, merge duplicates recorded under different names, and standardise units of measure.
4. Delete unused accounts and sub-accounts used once in five years.
5. Complete national IDs, economic codes and postcodes for active parties; gaps here break electronic invoicing and quarterly transaction reports later.

Step two: chart design and a mapping table

A migration is the best opportunity to fix the chart of accounts, on one condition: build a mapping table. One file with old code, old name, new code, new name and the reason for the decision, kept permanently. That single file makes year-on-year comparison possible and answers the auditor's question about why account headings changed. Design principles are in designing a chart of accounts.

Step three: opening balances

The new system's opening position must tie exactly to the closing balance sheet.

1. Take the closing trial balance from the old system and reconcile it to the final financial statements.
2. Extract sub-ledger detail for every control account: each customer, supplier, bank and petty cash fund.
3. Compare the sum of the sub-ledger to the control account balance. Resolve differences before migrating, not after.
4. Reconcile inventory by quantity and value, and document the valuation basis.
5. Migrate notes receivable and payable with due dates, numbers and banks — not as a single lump balance.
6. Confirm employee service, accrued leave and advance balances against the payroll file.
7. Post the opening entry and compare the new balance sheet with the approved statements; the difference must be zero.

If item codes changed, post the opening stock entry under the new codes at the existing carrying cost. Revaluing during migration breaches the standards and invites questions in an audit.

Step four: test and run in parallel

Migrate into a test environment first and run a full cycle before go-live: sales order, invoice, submission to the taxpayer system, receipt, sales return; then produce the trial balance, ledgers, aged receivables, the quarterly transaction file and one month of payroll for comparison with the old output. Test user permissions too.

Then keep sensitive areas parallel for one or two months. The exit criterion is concrete: key reports from both systems must agree across two consecutive periods. Announce a firm cut-off time for the old system so nothing is entered twice.

Step five: archive the old system

Keep a full database backup on two separate media, the installation files and licence details, signed PDF or printed statutory books and statements for each year, all filed tax returns and submission receipts, and the chart mapping file. Retention rules are covered in keeping financial records.

Common mistakes

Migrating without reconciling sub-ledgers to control accounts. Decommissioning the old system immediately. Changing the chart, the fiscal year and the inventory structure in one project. And handing the whole migration to the vendor without your own accountant signing off the balances — the vendor moves the data, but the accuracy remains your responsibility.

If you are planning a system change and want the migration path and balance reconciliation designed properly, I am glad to help.

Key takeaways

• Limit scope to master data and balances; keep detailed history in the old system.
• Cleaning master data before migration gives the highest return in the project.
• Any chart change needs a documented mapping table so year-on-year comparison survives.
• Opening balances must reconcile to approved financial statements with zero difference.
• Archive the old system in a runnable state rather than deleting it.