Now in open beta — close the books in 2 days, not 2 weeks.Read the case study →
Business · May 7, 2026 · 9 min read

Accounting software migration without data loss

Most SMBs put off switching accounting software for years because they are afraid of losing history. The fear is reasonable but the risk is manageable with a structured migration. Here is the 60-day playbook that gets you onto a better system without losing the data that matters.

What you actually need to migrate.

Three categories of data. Category A: must migrate (chart of accounts, opening balances at cutover date, active customers and vendors with tax IDs, active inventory with quantities and costs, open AR and AP, fixed asset register). Category B: nice to migrate (recent transaction history, last 12 months of P&L for comparatives). Category C: leave in the old system as read-only (transactions older than 12 months, archived customers/vendors, closed projects).

A common mistake is trying to migrate everything. The cleanup cost on category C data is huge and the value is low — you have the old system for reference if needed. Migrate category A clean, category B if it is easy, leave category C in the old system. This single decision saves most migrations from collapsing under their own weight.

The 60-day timeline.

Days 1-10: select system, set up account, design chart of accounts in the new system. Decide whether to clean up the COA during migration (usually yes) or migrate as-is and clean later (usually slower). Days 11-20: load category A data — opening balances, customers, vendors, inventory, fixed assets. Test extensively against expected balances.

Days 21-40: parallel run. Both systems live. New transactions entered in both. At each month-end, reconcile trial balances. Investigate every variance over €200. Days 41-60: cutover. New system becomes primary. Old system becomes read-only. Run the old system in read-only for at least 7 years per local tax authority retention requirements.

Days 1-10Select + COA designDays 11-20Load opening balancesDays 21-40Parallel run + reconcileDays 41-60Cutover, old read-onlyYear 7+Archive, still retained
Cutover is week 8, not week 1. The 20 parallel-run days are where data integrity gets proven before flipping the switch.
  • Days 1-10: System selection, COA design
  • Days 11-20: Category A data load, balance testing
  • Days 21-40: Parallel run, monthly reconciliation
  • Days 41-60: Cutover, old system read-only
  • Year 7+: Archive old system (still retained)

Choosing the cutover date.

The cutover date is the day after which the new system is the source of truth. Best options: end of fiscal year (cleanest, comparatives in one system), end of quarter (clean for tax filings), end of month (acceptable but not as clean). Worst options: mid-month, mid-quarter, or "whenever we are ready" (drift kills migration).

Pick the date in week 1 of the project and freeze it. Resist the temptation to delay because "we are not ready yet." Late migrations decay; an imperfect on-time cutover is better than a perfect-but-delayed one. Most cutover-day issues are minor and resolved within the first week.

Chart of accounts: clean it up now.

Migration is the right time to redesign the chart of accounts. Most SMBs have accumulated 200+ accounts over years, many duplicates ("Internet Expense" and "Internet" and "Web Connection"). A clean COA has 40-80 active accounts mapped to a clear category structure. Roll up the duplicates. Retire dead categories. Standardize naming.

A worked example. A 12-year-old French trading company had 287 accounts, 41 of them duplicates or near-duplicates. During migration to Nonari they consolidated to 64 accounts with a clear 4-level hierarchy. Reporting got dramatically clearer, and the bookkeeper stopped guessing which "Internet" account to use. The cleanup took 2 days and the benefit lasts forever.

Opening balances: the critical handoff.

At cutover, the new system needs every balance sheet account at its correct opening balance. Cash and bank balances per the bank reconciliation. AR per the open invoice list. AP per the open bill list. Inventory at quantity and weighted-average cost per item per branch. Fixed assets at cost and accumulated depreciation. Equity and retained earnings to balance.

The trial balance in the new system on cutover day must equal the trial balance in the old system on the same day. If it does not, find every variance before going live. Variances after go-live are 10x harder to investigate because new transactions cloud the picture. Spend the time pre-cutover; you will recoup it many times over.

Common pitfalls in migration.

Pitfall 1: trying to migrate without parallel run. Saves 30 days but loses the safety net. Almost always regretted. Pitfall 2: bringing forward errors from the old system. If the old AR has €18,000 of invoices that should have been written off 3 years ago, do not migrate them. Write them off pre-migration. Pitfall 3: cutting over on a Friday so issues hit the team on Monday. Cut over mid-week (Tuesday-Thursday) so the team has full attention.

Pitfall 4: not communicating with customers and vendors. Invoice formats may change, payment instructions may change, customer-portal links may change. Send a heads-up email / WhatsApp / SMS to top 50 customers and vendors a week before cutover. Pitfall 5: under-investing in training. The new system may be better but the team needs 2-4 weeks of active use before they are fully productive. Plan for the dip.

No parallel runNo safety netForward errors3-year-old bad ARFriday cutoverIssues hit MondayNo customer commsPayment chaosSkipped training2-4w productivity dip
Five migration pitfalls. Each survivable, all five together turn a 60-day cutover into a 6-month recovery.

How Nonari supports migration.

Five features that matter. One: bulk import for chart of accounts, customers, vendors, products, inventory. Two: opening balance entry that validates the trial balance balances. Three: branch-scoped inventory ledgers that handle multi-location opening positions cleanly. Four: parallel-run support — you can compare reports from Nonari versus the old system without contamination. Five: complete audit log so you can prove every entry during migration was deliberate and traceable.

For SMBs migrating from QuickBooks, Xero, Sage, ERPNext, or Excel, the import paths are documented and most migrations run on the 60-day timeline above. The bigger investment is in cleanup and training, not in the technical import itself. Get those right and the rest is mechanical.

Frequently asked

Common questions.

Should I migrate historical transactions or just balances?

For most SMBs, just balances. Importing 5 years of transaction history takes longer than the rest of the migration combined and rarely produces value. Keep the old system read-only for the historical detail. Migrate balances clean and start fresh in the new system.

How long do I need to keep the old system after cutover?

Read-only access for at least 7 years (IRS, HMRC, CRA, ATO and most other authorities sit in the 6-10 year retention window). Most legacy systems have an archive license at lower cost. Active editing should be disabled to prevent accidental changes that would break the historical record.

What if the new system has a different chart of accounts structure?

Design the new COA in the new system's preferred structure. Map old accounts to new accounts during migration. Keep a mapping table for reference. Some old accounts may map to multiple new ones (split) or multiple old to one new (consolidate). Document the mapping for future reference.

Can I run the migration in-house or do I need a consultant?

For SMBs with a competent finance manager, in-house works. For SMBs where the bookkeeper is the most senior finance person, get a consultant for the migration phase. Cost: €3,000-€15,000 typical for an SMB migration depending on complexity. Worth it to avoid mistakes that cost more than the consultant fee.

Try nonari

Put your books on autopilot.

Free to start. No credit card. Bring your books, kick the tires, export everything if you decide to leave.