The migration that goes wrong two different ways
Switching accounting software is one of the highest-stakes things a small business does to its books, and it fails in one of two predictable ways. Either you bring over too little — starting fresh with no balances, so your reports show a business that apparently sprang into existence last Tuesday — or you try to bring over too much, hand-keying years of individual transactions until errors creep in and nothing reconciles.
The clean path is neither. You carry over balances, not history: a snapshot of where the business stood on a chosen date, entered as opening balances, then proven correct by reconciling. This guide walks through that cutover. (General education, not accounting advice.)
Step 1: Pick a cutover date
Choose a clean date to be the dividing line between the old system and the new. The first day of an accounting period is ideal — the start of a month, a quarter, or best of all a fiscal year. Everything dated before the cutover lives in the old system (keep it accessible — you'll need it for any prior-year reference). Everything on or after the cutover gets recorded in the new one.
Picking a period boundary matters because your P&L resets at the start of each period anyway. Cut over on the first of the fiscal year and the new system shows a complete, clean year with no awkward partial-period seam in your income statement.
Step 2: Get a trustworthy closing balance sheet
Your opening balances in the new system come straight from the closing balance sheet of the old one, dated the day before cutover. Before you trust it, make sure the old books are actually closed properly:
- Reconcile every bank and credit-card account to its real statement, so cash is correct.
- Run an AR aging report so you have the exact list of unpaid customer invoices.
- Run an AP aging so you have the exact list of unpaid vendor bills.
- Confirm the trial balance balances — total debits equal total credits — which is your proof the source data is internally consistent.
A migration can only ever be as accurate as the closing balance sheet you start from. Garbage in, garbage out — so this cleanup step is the one not to rush.
Step 3: Set up the chart of accounts first
Before entering a single balance, build your chart of accounts in the new system. This is a natural moment to tidy it — merge duplicate accounts, drop ones you never use — but resist the urge to redesign everything at once. The closer your new chart mirrors the old structure, the easier it is to verify the migration tied out. Reorganize after you've confirmed a clean cutover, not during it.
Step 4: Enter opening balances
Now enter the closing balances as of the cutover date. Two approaches, depending on the account type:
- Summary balances for most accounts. Cash, fixed assets, loans, owner's equity — enter each as a single opening balance figure. You don't need the transaction history behind them; you need the balance to be right.
- Itemized detail for AR and AP. This is the one place to enter line-by-line. Re-create each open customer invoice and each unpaid vendor bill individually, so you can still collect and pay them — and so your aging reports work — in the new system. You only need the open items, not every invoice ever issued.
The balancing entry for the whole opening snapshot typically lands in an opening-balance equity account, a temporary clearing account that absorbs the offset while you enter everything. By the time you're done, it should net out and be cleared to retained earnings or owner's equity.
Step 5: Prove it tied out
This is the step people skip, and it's the most important. After entering opening balances, run a balance sheet in the new system dated the cutover date and compare it line by line to the old system's closing balance sheet. They must match exactly. If they don't, the difference is sitting in opening-balance equity, telling you precisely how much you're off.
Then, going forward, reconcile the first month in the new system against real bank statements. A clean first reconciliation is the final proof that opening cash was right and the cutover held. Treat that first month-end close as the acceptance test for the entire migration.
What you deliberately leave behind
You are not trying to reproduce years of detail in the new system. Prior-period transaction history stays in the old system (or an export) for reference. What crosses the cutover is the state of the business — balances, open invoices, open bills — not the full ledger that produced them. That restraint is what keeps a migration clean instead of turning it into months of data entry where new errors outnumber the history you preserved.
Done this way, the switch is anticlimactic in the best way: the new system opens on day one showing exactly the same financial position as the old one closed on, and every report from there forward is built on a foundation you've proven correct.
Hosting Books supports an opening-balance setup that mirrors your prior closing balance sheet — summary balances for most accounts, itemized open AR and AP — so a switch reconciles cleanly from the first month.
This article is general educational information about accounting concepts and is not accounting advice for your specific situation.