The short answer: migrate balances, keep history read-only.
Every migration that goes wrong starts with the same ambition: bring everything across. Every one that goes right starts with a sort. Category A must migrate — the chart of accounts, opening balances at the cutover date, active customers and suppliers with their tax IDs, inventory with quantities and unit costs, open receivables and payables, the fixed-asset register. Category B is nice to have — the last twelve months of transactions, so this year’s reports show comparatives. Category C stays behind, read-only — older transactions, archived contacts, closed projects.
The old system does not disappear when you stop paying for edits; it becomes an archive you can open any time. That single reframe removes most of the fear. You are not moving a warehouse; you are opening a new set of books that starts from a verified position, with the old books on the shelf behind you. Migrate A cleanly, B if it is cheap, and leave C where it is.
What “losing data” actually means — the four ways it happens.
Data is rarely lost in a migration the way a file is lost. It is lost in four quieter ways. One: an incomplete export — you took the customer list but not the customer balances, the item list but not the unit costs. Two: a bad mapping — old “Internet”, “Internet Expense”, and “Web Connection” all landed in different new accounts, or one of them in none. Three: the wrong cutover date — you started the new books mid-month, so half a month lives in each system and neither report is whole.
Four is the one nobody plans for: history you thought you did not need. The tax authority asks for a three-year-old invoice; the old system’s subscription lapsed; the export you kept was a summary. The defence against all four is the same discipline — a complete export you verify BEFORE anything is loaded, a written mapping, a period-end cutover, and an old system kept readable for the retention window (six to ten years in most jurisdictions).
Step 1 — Export everything from the old system.
Do this before you touch the new system, and do it completely, even for data you will not migrate: the export is your insurance. Every mainstream product exports these as CSV or Excel; the trap is not the format but the omissions.
- Chart of accounts — every account, active and inactive, with type and number
- Trial balance at the intended cutover date — this is the target the new system must reproduce
- Customers and suppliers — with tax IDs, terms, and current balances
- Open invoices and open bills, individually — the AR and AP ageing, not just the totals
- Inventory — quantity on hand AND unit cost per item (per location if you have several)
- Fixed assets — cost, accumulated depreciation, method
- Bank statements for the last period, so the cash figure can be proven independently
- Full transaction history export, even if you never load it — the archive copy
Step 2 — Map the chart of accounts (and clean it while you can).
Migration is the one moment a chart of accounts can be redesigned without chaos, because no transactions depend on the new structure yet. Most businesses arrive with two hundred accounts accumulated over years, dozens of them duplicates. A clean chart has forty to eighty active accounts in a clear hierarchy. Build the mapping as a written table: every old account on the left, its new home on the right — one-to-one, several-to-one (consolidate the three internet accounts), or one-to-several (split a lumped expense) — and keep that table forever; it is how anyone reads the old books against the new.
A worked example: a twelve-year-old trading company had 287 accounts, 41 of them duplicates or near-duplicates. During migration they consolidated to 64 accounts in a four-level hierarchy. The cleanup took two days; the bookkeeper stopped guessing which “Internet” to use, and every report since has been readable. If your product tracks locations as classes or tags, this is also the moment to decide how they map — in a true multi-branch system they become branches, not accounts.
Step 3 — Load opening balances until the trial balance foots.
The new system starts from one entry: the opening balance journal, dated the cutover date, carrying every balance-sheet account at exactly the figure the old trial balance shows. Cash from the bank reconciliation, receivables from the open-invoice list, inventory at quantity times unit cost per item, fixed assets at cost less accumulated depreciation, payables from the open-bill list, loans at the current principal — and equity as the figure that makes it balance, which it will only do if everything else is right.
That is the whole test: the opening trial balance in the new system must equal the closing trial balance in the old system on the same date, to the cent. If it does not, you have found a data problem NOW, while it is one entry and one afternoon — not in three months, buried under new transactions. Load receivables and payables as individual open documents, not as one lump, so the ageing and the customer statements are right from day one.
Step 4 — The parallel run: twenty days that prove nothing was lost.
For roughly twenty days after the opening balances load, enter new transactions in BOTH systems. At the next month-end, pull the trial balance from each and compare line by line; investigate every variance over a small threshold (a few hundred dollars, or less for a small business). A clean parallel close is the proof the migration worked. A variance is a mapping or export error caught while it is cheap.
It costs double entry for three weeks, and every team resents it in week one. It is still the single step most worth keeping. Migrations that skip it discover their errors at year-end, in front of the accountant, with nine months of transactions on top.
Step 5 — Cut over on a period end, and keep the old system readable.
The cutover date is the day after which the new system is the only truth. The best choice is the start of a fiscal year (every comparative lives in one place); a quarter end is clean for tax filings; a month end is acceptable. Mid-month is the worst option and the most common, because it is “whenever we were ready.” Pick the date in week one and freeze it; late migrations decay.
Cut over mid-week, not on a Friday, so problems surface with the team present. Tell your top customers and suppliers a week ahead if invoice formats or payment details change. Budget two to four weeks of slower work while the team learns — the dip is real and it is temporary. And keep the old system in read-only mode for the retention window: the archive export from Step 1 is the backup, the old login is the convenience.
Changing accounting software mid-year: the split-year problem and two ways around it.
Most guides tell you to wait for the new financial year. Real businesses change accounting software mid-year, because the old system breaks in March, not on 31 December. The problem a mid-year switch creates is a split year: January to June in the old system, July to December in the new one, and an annual profit and loss, a tax return and a set of payroll year-to-date figures that now have to be stitched together from two places. The fix is not to wait; it is to choose, on purpose, one of two methods.
Method A, carry the year: cut over on a month end, load the balance-sheet opening balances exactly as in Step 3, then post the year-to-date profit and loss into the new system as one summary journal per elapsed month, dated the last day of each month, with every revenue, cost-of-sales and expense account at the figure the old system shows. The new system then produces a complete annual profit and loss and correct monthly comparatives, and the old system is only ever needed for transaction-level detail. Use it when six months or fewer have elapsed, or whenever you want one annual report from one place.
Method B, split the year: cut over on a month end with balance-sheet balances only, keep the old system as the record for the months before the cutover, and at year end let your accountant add the two profit and loss reports together for the tax return. It is less work on the day and more work at year end, and every comparative for the first year is manual. Use it when you are within two or three months of year end, or when the old system is so unreliable that its year-to-date figures are not worth carrying. If you are that close to year end and the old system still works, the honest advice is to wait and cut over on the first day of the new year.
- Cut over on a filing-period boundary: a quarter end if you file sales tax or VAT quarterly, so no return is split across two systems
- Payroll year-to-date per employee (gross pay, tax withheld, contributions) must be entered into the new payroll before the first run, or the year-end statements will be wrong
- Fixed assets carry accumulated depreciation to the cutover date, including the current year’s charge to date, so the annual depreciation is not doubled or skipped
- Open invoices and bills load individually, dated as originally issued, so ageing and statements are right on day one whichever method you choose
- Inventory loads at quantity times unit cost at the cutover date; the year-to-date cost of sales stays in the P&L journals, not in stock
Method A worked: the year-to-date journal that fills the P&L without moving the balance sheet.
Take the opening balances from Step 3, loaded on 30 June with equity as the balancing figure of 37,700. That equity already contains this year’s profit, because the balance sheet at 30 June is the result of everything that happened up to 30 June. So the year-to-date journal must not touch the balance sheet at all: it debits each cost and expense account, credits each revenue account, and puts the net profit against the same opening-equity account as the offset.
Say the old system shows six months of revenue of 96,000, cost of sales of 58,000 and operating expenses of 24,000, a profit of 14,000. The journal debits cost of sales 58,000 and expenses 24,000, credits revenue 96,000, and debits opening equity 14,000 to balance. Opening equity falls from 37,700 to 23,700, which is exactly the equity at the start of the year; the profit and loss now reports the 14,000 the year has earned; total equity on the balance sheet is unchanged at 37,700. Post one such journal per month with that month’s figures if you want monthly comparatives, or a single journal dated the cutover date if you only need the annual total. Either way, the check is the same as in Step 3: the new system’s year-to-date profit must equal the old system’s to the cent before the parallel run starts.
Switching from QuickBooks, Xero, Zoho, Sage, Manager.io, Tally or a spreadsheet.
The steps are identical; the exports differ. QuickBooks Online exports lists and reports as Excel/CSV, and its classes or locations need a deliberate decision — branches in a multi-branch system, or nothing. Xero’s tracking categories are the same question. Zoho Books exports every module as CSV from its settings. Sage products export CSV per ledger. Manager.io exports each tab as TSV and has no API, so the discipline is manual but the data is clean. Tally exports XML and Excel; its stock groups and godowns become categories and locations.
A spreadsheet is the easiest source of all, because there is no history to argue about: verify the closing balances, build the opening entry, start clean. Whatever the source, the trial-balance test in Step 3 is the same, and it is the only test that matters.
Reporting tools, compliance systems, closed books: the same four rules.
Everything above is written for accounting software because that is where the arithmetic is hardest, but none of the four rules is about accounting. Any system of record — the reporting stack, the compliance register, a portfolio whose book is already closed — is moved the same way: export it completely and verify the export before you load anything; decide for each thing whether it is a BALANCE you carry across or HISTORY you archive; cut over on a period boundary; run both systems side by side until they agree, then keep the old one readable for the retention window.
What changes between systems is only the answer to the second question. Here is what "historical data" actually means in the three cases people ask about most.
- Reporting or BI software: the rows live in your warehouse and source systems, not in the reporting tool. What a switch actually risks is the DEFINITIONS — metric logic, filters, saved views, scheduled sends. Export those (SQL, metric files, dashboard JSON), rebuild your ten most-opened dashboards first, and run both tools over the same closed period until every figure matches. History is not lost by switching; it is lost by rebuilding a metric slightly differently and never noticing.
- Compliance, certificate or licence systems: the artefact IS the record. A certificate carries an issue date, an issuer and often a signature, and a re-rendered copy is not the same document. Migrate the register as data, but export and keep the original signed files too, and do it before the old licence lapses — a lapsed subscription can put the archive behind a paywall or take it offline entirely.
- Closed-book portfolios and prior-year books: do not migrate them. A closed book is finished; its value is being readable, not editable. Carry its closing position across as the new system opening balance, keep the book itself as a read-only archive, and write a one-page index saying what lives where and who can open it.
- Payroll and HR systems: year-to-date figures per person must be loaded before the first run in the new system, or the year-end statements will be wrong. This is the one migration where a mid-year cutover has a hard, non-negotiable data requirement.
- Inventory and order-management systems: the stock number is the easy part, because you can recount it. What a switch actually risks is the movement history that explains your costs and the mappings that connect a SKU to each sales channel listing. Carry on-hand quantity at cost, export the movement and order history as an archive before the licence ends, and re-map every channel before the first sync runs, or the first day of orders lands against the wrong products.
How Nonari handles the switch. (Full disclosure: ours.)
Nonari is the product we build, so weigh this accordingly. It is designed around the steps above: bulk CSV import for the chart of accounts, customers, suppliers, products, and inventory; an opening-balance entry that refuses to post until it foots; branch-scoped inventory so multi-location opening stock lands per branch at its own cost; and an audit log that shows every migration entry as deliberate. Businesses have moved in from QuickBooks, Xero, Manager.io, Tally, and spreadsheets — the technical import is the small part; the cleanup and the parallel run are where the time goes, and the guide above is the same one we use.
If you are still deciding where to switch to, the AI-accounting comparison linked below names who should not pick us. Plans start at $29 a month for a single location and $70 for up to three branches, with a 15-day free trial — long enough to load your opening balances and run the parallel test before paying anything.