Bookkeeping · Cleanups & Fixes · Guide · Working level
Switching bookkeeping software without importing the mess
What to bring to a new ledger (balances and open items), what to leave behind (transaction history stays archived), how to post opening balances, and a cutover checklist with one month of parallel running.
The worst way to change bookkeeping software is to press the vendor's "import everything" button, because a ledger's problems travel better than its virtues. The right way is a clean cutover: reconcile and close the old file through a chosen date, carry only balances and genuinely open items into the new one, run the two in parallel for a month, and archive the old file read-only. You lose nothing — history lives in the archive — and you gain a ledger that starts life provably correct.
This guide covers the what-to-bring decision, the opening-balance mechanics, the parallel month, and a cutover checklist you can run as written.
Why history stays behind
Three reasons, in descending order of importance:
- Imported history imports the mess. Every duplicate, every miscategorized expense, every forced reconciliation travels intact. If the old file were clean enough to import wholesale, you probably wouldn't be leaving it.
- Conversions are lossy. Reconciliation status, payment applications, and links between documents rarely survive a cross-platform import. What arrives looks like history but no longer reconciles, which is worse than absence — it invites false confidence.
- The archive satisfies retention. Keeping the old file (plus exported PDF/CSV copies of the general ledger, trial balances, and reports) meets record-keeping needs; IRS Publication 583 frames retention in terms of supporting filed returns, which the archive does regardless of what software currently runs the business.
The exception: staying on the same platform and merely starting a new file — as in a rebuild after severe damage (/bookkeeping/cleanups-fixes/books-cleanup-playbook covers when that's warranted) — follows this same balances-only method. Cleanup by migration and migration after cleanup are the same procedure.
Choosing the cutover date
Fiscal year-end is the gold standard: the new file then contains only complete years, the tax return for each year maps to exactly one system, and comparative statements never straddle platforms. If you cannot wait for year-end, any month-end works, provided that month is fully reconciled first. Mid-month cutovers are never acceptable — one bank statement would span two systems and neither could reconcile it.
Cutover date options compared.
| Option | Tax-year mapping | Effort | When to choose |
|---|---|---|---|
| Fiscal year-end | One return, one system | Must close the full year first | Whenever the switch can wait |
| Quarter-end | Return spans systems; quarterly filings map cleanly | Moderate | Payroll/sales-tax-heavy businesses mid-year |
| Any month-end | Return and some filings span systems | Lowest wait | The old system is failing now |
| Mid-month | Statements unreconcilable | — | Never |
What crosses, what stays
The packing list.
| Item | Bring? | How |
|---|---|---|
| Chart of accounts | Yes, pruned | Rebuild deliberately; a migration is your one chance to fix a bloated chart |
| Balance sheet balances at cutover | Yes | Opening balance entries (below) |
| Open customer invoices | Yes, individually | Re-enter each with original date, number, and amount |
| Open vendor bills | Yes, individually | Same |
| Uncleared checks and deposits | Yes, individually | Enter so the first reconciliation can clear them |
| Customer and vendor master records | Yes | Import or re-enter; verify W-9 data survives (Form W-9) |
| Fixed asset and loan schedules | Yes, as records | Balances via opening entries; keep the preparer's schedules as the subledger |
| Inventory quantities and costs | Yes, from a physical count | Never from the old system's (possibly negative) quantities — see /bookkeeping/cleanups-fixes/inventory-negative-quantities |
| Transaction history | No | Archive the old file read-only; export GL and reports to PDF/CSV |
| Recurring transactions, memorized reports | Rebuild | Re-create in the new system's idiom |
Year-to-date payroll totals deserve special care on a mid-year cutover: the new system (or payroll service) needs per-employee YTD wages and withholding so that Form W-2 and the remaining Form 941 filings come out whole. Tie those totals to the last filed quarter before entering them — the method in /bookkeeping/cleanups-fixes/payroll-liabilities-wrong.
Posting the opening balances
Work from the old file's final trial balance — reconciled, reviewed, and blessed by the preparer if the cutover is a year-end that has been filed. The core entry stamps in every balance sheet account except AR, AP, and bank items that need item-level detail:
| Account | Debit | Credit |
|---|---|---|
| Checking account | 18,450 | |
| Inventory | 22,300 | |
| Machinery & equipment | 84,000 | |
| Accumulated depreciation | 36,000 | |
| Note payable — vehicle | 28,750 | |
| Credit card payable | 3,120 | |
| Owner's equity | 56,880 |
Equity is the balancing figure and must equal the old file's total equity at cutover. AR and AP are excluded here — they enter as individual open invoices and bills.
Then the item-level pieces, each of which replaces a line the entry above deliberately omitted:
- Enter each open invoice with its original date and number, offsetting to opening equity (most platforms do this automatically for invoices dated before the start date). The AR total must equal the old file's AR at cutover.
- Enter each open bill the same way; AP total ties likewise.
- Enter each uncleared check and deposit dated pre-cutover, so the first bank reconciliation in the new file can clear them against the statement. If the old file carried ancient uncleared items, resolve them before migrating rather than carrying them across — /bookkeeping/cleanups-fixes/uncleared-transactions-cleanup.
- Zero out Opening Balance Equity. Platforms that auto-post setup balances to an "Opening Balance Equity" account expect you to reclassify it to real equity once setup is done. A new file that launches with a lingering OBE balance has already started collecting mess — the fix is /bookkeeping/cleanups-fixes/opening-balance-equity-cleanup.
The parallel month
Run one full month in both systems. It is tedious by design — the tedium is the test.
- Post the month's activity in both files. New system as the system of record; old system as the shadow.
- Reconcile the same bank statement in both. Both must reconcile without plugs.
- Compare the month-end trial balances. Every difference is either a known, documented improvement (a pruned account, a corrected categorization) or a defect to fix in the new file.
- Compare one operational report each — AR aging, AP aging, and P&L — for the same story.
- Retire the old file to read-only once the trial balances agree. Revoke edit access; keep read access indefinitely.
One month suffices. Two parallel months doubles the bookkeeping workload for marginal assurance; if the first month ties out, the migration mechanics are proven.
Illustrative distribution for a small business migrating at year-end; open-item re-entry dominates when AR/AP volume is high.
The cutover checklist
Run it top to bottom; each row has an artifact.
| Step | What you do | What proves it's done |
|---|---|---|
| 1 | Reconcile every account in the old file through the cutover date | Reconciliation reports, no plugs |
| 2 | Resolve stale AR, AP, and uncleared items in the old file | Clean agings at cutover |
| 3 | Export and archive: GL, trial balance, agings, statements (PDF/CSV) | Archive folder, backed up |
| 4 | Freeze the old file (closing date or read-only) | Lock confirmed |
| 5 | Build the new chart of accounts | Approved account list |
| 6 | Post opening balance entries | New TB equals old TB |
| 7 | Enter open invoices, bills, uncleared items individually | AR/AP/uncleared totals tie |
| 8 | Zero Opening Balance Equity | OBE = 0 |
| 9 | Connect bank feeds from cutover date forward only | Feed start date verified |
| 10 | Parallel-run one month; compare trial balances | Signed-off comparison |
| 11 | Retire the old file to read-only permanently | Access list updated |
When a clean cutover is the wrong call
Two honest exceptions. Businesses with long-running jobs or projects (contractors, agencies) sometimes need transaction-level project history in the new system for job costing; there, import the open projects' transactions only — not the whole file — and reconcile the imported subset to the archive. And a business under audit or in a lender workout may be told to keep continuous transaction history in one system; follow the examining party's requirement and delay the migration instead. For everyone else, the balances-only cutover is the rare bookkeeping procedure with almost no downside: the history is not lost, only left where it can no longer do harm.
Frequently asked questions
- Should I import all my transaction history into new bookkeeping software?
- Usually no. Bring opening balances as of the cutover date and the open items behind them — unpaid invoices, unpaid bills, uncleared checks — and leave the transaction history in the old file, kept read-only as an archive. Importing years of history imports every duplicate and miscategorization along with it, and record-retention needs are met by the archive.
- What is the best cutover date for a bookkeeping software migration?
- The first day of a fiscal year is best, because the new file then contains complete years and the tax return maps to one system. Second best is the first day of any month, immediately after that month's reconciliations are done. Never cut over mid-month — you would split a bank statement across two systems and neither could reconcile it.
- What is an opening balance entry in new bookkeeping software?
- It is the entry (or set of entries) that stamps each balance sheet account's cutover-date balance into the new file: debit assets, credit liabilities and equity, with AR and AP entered as individual open invoices and bills rather than lump sums so payments can be applied to them later. Totals must tie to the old file's final, reconciled balance sheet.
- How long should I run old and new bookkeeping systems in parallel?
- One full month is usually enough. Keep the old file alive through one complete cycle in the new system, reconcile the same bank statement in both, and compare the resulting trial balances. If they match, retire the old file to read-only. Longer parallel runs double the workload for little added assurance.