Choosing new accounting software is the easy part. The hard part starts the morning after you've signed up, when you realise that "moving your books" means deciding what happens to five years of transactions, a chart of accounts that grew organically, seventeen unpaid invoices, three bank feeds, a payment gateway connection, and the recurring invoices that go out on the 1st whether you're ready or not.
The takeaway: treat this as a data migration with a fixed cutover date, not as a software purchase. The failure mode isn't losing data — it's ending up with opening balances nobody can defend, and a year where the comparatives don't tie.
If you're still choosing between candidates, our guide to choosing accounting software covers the selection criteria, and a category resource like Asraf Masum — which publishes reviews and roundups of accounting and business software — is a quick way to see what's on the market before you shortlist. This guide starts after the decision.
First: is the switch worth it?
Migration costs real hours, and the pain is front-loaded. Reasonable triggers:
- The current system genuinely can't do something you need (multi-currency, a compliance requirement, inventory, payroll integration).
- You're paying for a tier built for a business much larger or much smaller than yours.
- Your accountant can't work in it, or charges extra because of it.
- It's being discontinued, or its support has quietly decayed.
Poor triggers: a slick demo, a discount, and "everyone uses the other one now." A tool you know well is worth more than a marginally better one you don't.
Pick the cutover date first
Everything else follows from this. The start of a financial year is the cleanest option: one system holds one complete year, comparatives stay intact, and your accountant only has to look in one place per period.
Second best is the start of a tax or reporting quarter — messier, but survivable if you document it.
Mid-period cutovers are where migrations go wrong. Avoid one unless something forces it, and if it's forced, write down exactly which transactions live where before you start.
Also check what else is happening that month. Migrating during your busiest trading period, a VAT/GST filing week, or a payroll run is a choice you'll regret.
Decide what actually moves
This is the decision most people get wrong by assuming "everything" is both possible and desirable. In practice, migrations are usually layered:
Always migrate: - Chart of accounts — and use the move to clean it. Merge the duplicates that accumulated, remove accounts with no activity, and get the structure to match how you actually want to read a profit and loss. - Customers and suppliers, with current contact and payment details. - Opening balances as at the cutover date — the trial balance from the old system. - Open items: unpaid customer invoices, unpaid supplier bills, undeposited funds, and anything unreconciled. These have to carry over individually, not as a lump, or you can never match a payment to what it settles. - Products/services and tax codes, if you invoice from the system.
Usually don't bother migrating: - Years of historic transaction detail. It's the most expensive part, the most error-prone, and the least used. Which brings us to the important bit:
Keep the old system readable instead. Before you cancel anything, export full reports — trial balance, profit and loss, balance sheet, general ledger detail, aged receivables and payables, bank reconciliation reports, and the tax returns you filed — for every period you're required to retain. Save them as PDFs and as CSV/Excel, in a dated folder. Where the vendor allows a cheap read-only or archive tier, take it for the first year.
Retention obligations for accounting records typically run for several years, and they vary by jurisdiction and entity type. Confirm what applies to you before you let a subscription lapse; the cost of an extra year of archive access is trivial next to reconstructing records you no longer have.
Map the chart of accounts before you import
Do this in a spreadsheet, with three columns: the old account, the new account, and a note for anything that isn't a clean one-to-one. Every migration produces a handful of awkward cases — an account used for two purposes, a suspense account somebody was "going to sort out", a category the new system handles structurally rather than as an account.
Resolve those before the import. Fixing a mapping after you've posted three months of transactions means re-coding them.
The migration sequence
- Freeze the old system at the cutover date, at least for backdated entries. Agree with everyone that nothing new gets posted there.
- Reconcile the old system completely. Every bank account reconciled, every control account agreed. You cannot produce trustworthy opening balances from a set of books that didn't balance. This is the single most skipped step and the source of most migration pain.
- Export everything — reports, ledgers, lists, and the raw data if the system allows it.
- Set up the new system properly: financial year, tax settings and registration details, chart of accounts from your mapping, users and permissions.
- Import the master data — customers, suppliers, items — and clean it on the way in. Migrations are the one moment when deduplication is easy.
- Enter opening balances from the old trial balance, then the open items individually.
- Prove the opening balances: the new system's opening trial balance must equal the old system's closing trial balance. To the penny. If it doesn't, stop and find out why — don't post an adjustment to make it agree.
- Reconnect the operational plumbing: bank feeds, payment gateway, e-commerce or POS integrations, recurring invoices, invoice templates and numbering. Invoice numbering deserves special care — a duplicated or reset sequence causes problems well beyond accounting.
- Run one period in parallel if you can spare the effort. Post the same month in both systems and compare the profit and loss and bank balance. It's tedious, and it catches configuration errors — wrong tax code defaults, wrong account mapping — while they've affected one month instead of twelve.
Tell your accountant before, not after
Your accountant has a stake in this and usually has migration experience. Tell them the cutover date in advance, agree who signs off the opening balances, and ask which reports they want preserved from the old system and in what format. An accountant who finds out in March that you switched systems in October will spend billable hours discovering what happened.
If the migration is happening alongside anything structural — a change in registration, a new entity, a new tax obligation — get professional input on sequencing rather than doing both at once and hoping.
What "done" looks like
- Opening trial balance in the new system matches the old system's closing trial balance.
- Every bank account reconciles in the new system for the first full period.
- Aged receivables and payables match the old system's closing lists, invoice by invoice.
- The first tax return filed from the new system agrees with your own workings.
- Historic reports are archived, dated, and stored somewhere that isn't only in the old vendor's cloud.
Tick those and the switch is genuinely finished. Skip them and you'll find out at year end.
Common failure modes
- Migrating unreconciled books. Garbage in, permanently.
- Cancelling the old subscription too early. Keep access until the first full period reconciles in the new system.
- Importing open invoices as a single total. Now no payment can be matched.
- Ignoring tax settings. Default tax codes on imported items are the classic silent error — wrong on every subsequent transaction.
- Migrating a messy chart of accounts unchanged. You've paid the cost of the move without taking the one free benefit.
- Doing it during a filing week. Self-inflicted.
FAQ
Can I migrate mid-year? You can, and sometimes you must. It costs you: the year's comparatives are split across two systems, and someone has to document precisely where the boundary sits. If you have the choice, wait for the year start.
Will I lose my transaction history? Not if you export it before you leave. Most businesses keep history as exported reports and ledgers rather than re-importing every transaction, which is both cheaper and adequate for almost every purpose — including most queries from an accountant or tax authority.
How long does a migration take? For a small business with clean books, planning and set-up is often a few days of work, with a parallel month afterwards. Unreconciled books, inventory, multi-currency, or payroll can multiply that considerably.
Should I pay someone to do it? If your books are complex, if the old system's data is untidy, or if you can't afford to get opening balances wrong, yes — a bookkeeper or accountant who has done several migrations will be faster and will spot the tax-code and mapping traps in advance.
Still comparing candidates before you commit to a move? Category resources such as Asraf Masum, which publishes reviews and roundups of accounting and business software, are a quick way to see the landscape and build a shortlist — then verify current pricing and limits with the vendor, and test your real data in a trial before you set a cutover date.
