Most teams do not fail the QuickBooks transition because the destination product is “missing a feature.” They fail because cutover is a project: you are moving a system of balances, not copying a logo. Hosted suites love to imply there is a single “import everything” button. In the field, those converters are brittle on partial history, class tracking, inventory layers, and messy historical adjustments. A deliberate, documented cutover almost always beats a converter that silently rounds, drops lines, or maps accounts into buckets you will regret at year-end.
Decide the cutover shape before you touch CSVs
There are two common patterns. A clean balance-sheet cutover posts opening balances as of a chosen date and runs new detail in the new system. A parallel run keeps the old system read-only for a month while you validate reports. Hybrid approaches exist, but they need explicit rules: what is source of truth for AR/AP during overlap, and who is allowed to post in the legacy file.
- Pick an as-of date aligned with a real boundary: month-end, quarter-end, or a slow operational week—not “whenever someone has time.”
- Freeze configuration in the old system: new accounts, items, and tax codes should slow down until mapping is stable.
- Name an owner for the chart mapping and for tie-out sign-off (often the bookkeeper + controller + external CPA on one email thread).
Import order that prevents “foreign key regret”
Accounting data is relational even when it looks like flat spreadsheets. If you import taxable invoice lines before tax codes exist, you get rework. If you import items before the chart accounts they point at, you get orphan rows. A boring order wins:
- Company profile and functional currency decisions (hard to unwind later).
- Chart of accounts (QuickBooks-style number/name/type exports map cleanly when codes are consistent).
- Sales tax codes if you use line-level tax.
- Contacts and items.
- Inventory locations before first receipts if you are multi-site.
- Bank import rules after the chart exists (rules reference accounts).
- Bank registers tied to cash accounts.
- FX rates if you are multicurrency.
- Opening trial balance as of the cutover date.
Privbooks documents the same philosophy on the in-app Backup tab: import in an order that lets references resolve. For a deeper look at why CSV remains the honest backbone when feeds fail, read bank CSV and live feeds.
Opening balances: the real “migration”
For many SMBs, the cutover is not “100,000 historical invoices replayed.” It is a defensible trial balancethat ties to the prior system's close, with supporting AR/AP aging that your CPA can reconcile. That is why opening balance workflows matter more than glossy migration marketing. Small imbalances should be visible and posted to a dedicated equity plug with documentation—not hidden in rounding.
Coordinate with your CPA early
Your preparer cares about continuity: does the closing retained earnings story still tie? Are AR and AP detail consistent with aging? Will they receive GL detail in a format they can re-perform in Excel? If you standardize exports (trial balance, GL, tax preparer packet) you reduce back-and-forth. See also what a strong preparer handoff contains.
Why local-first helps during transitions
During cutover, you will iterate: import, spot a mapping mistake, adjust, re-import. A ledger that is physically on your machine as a portable database file changes the psychology—you are not begging a vendor portal for a re-export on their schedule. For portability mechanics, read browser SQLite accounting and backups and why local data feels faster for daily work.
Closing thought
The goal is not to “clone QuickBooks.” The goal is to land in a system where your balances are explainable, your exports are repeatable, and your team can close without superstition. If that matches how you operate, start on Starter and use Backup imports to stage the cutover methodically.