Skip to main content
Migrating to DualEntry moves your chart of accounts, classifications, customers and vendors, items, and historical transactions out of your current system and into DualEntry. Everything arrives as live records rather than summary balances. This page is the map: what happens before you commit, what’s different by source system, and how the cutover itself is run and checked.

How DualEntry runs a migration

Every migration starts as an evaluation: a sandbox organization seeded from your own books. You judge DualEntry against your real chart of accounts and transaction volume rather than a demo dataset. Migration data scope is the authoritative reference for what moves automatically, what you recreate by hand, and what an ongoing connector supplies instead. It applies equally to the sandbox and to production. The cutover itself follows the same sequence regardless of source system. The cutover runbook covers when posting stops in the old system, the hour-by-hour sequence DualEntry’s team runs, and what’s needed from you at each step. Afterward, validating and tying out the migration proves the migrated books match the old system: trial balance by period, retained earnings roll-forward, and AR/AP subledger agreement. If something goes wrong along the way, migration failure modes covers what recovers on its own, what gets re-run, and how to trial a migration before committing to it. Data handling during a migration covers where source credentials and exported data live in the meantime, how long each is retained, and what SOC 2 covers.

Guides by source system

Last modified on August 28, 2026