Accounting Data Migration: Moving Financial Data Safely

Accounting data has one test that most data doesn’t: after the migration, the books still have to balance. Every account, every customer balance, and every tax total has to match, to the penny. That makes reconciliation the centre of the plan. The other big decision comes first: whether to move the full transaction history, or opening balances plus an archive of the old system.

The key decisions at a glance

Decision	Options	What usually decides it
How much history	Full history, recent years only, or opening balances	Reporting and audit needs, data quality, cost
Cutover date	Any day, or a period end	Period ends make reconciliation far simpler
Chart of accounts	Keep, map, or redesign	Whether the old structure still fits the business
Open items	Migrate individually or as balances	Whether you need to chase and match them later
Old system	Switch off, or keep read-only	Audit and retention requirements
Sign-off	Who confirms the numbers are right	Usually finance, not engineering

Full history or opening balances?

Full history keeps everything in one place and lets you report across the move, but it means mapping years of transactions, including the odd ones, and reconciling all of them.

Opening balances move the balances at the cutover date, plus open items such as unpaid invoices and bills, and leave history in the old system or an archive. It’s much less work and risk. The cost is that reports spanning the move need both systems.

Many teams pick opening balances plus a read-only archive, then migrate a year or two of history only if reporting really needs it.

Mapping is where the books break

• Chart of accounts. Account codes, types and hierarchies rarely line up one to one.
• Tax codes. Rates, inclusive versus exclusive amounts, and country-specific rules.
• Currencies. Which exchange rate applies to historical amounts, and how realised and unrealised gains are handled.
• Contacts. Duplicates, merged records, and contacts that are both customers and suppliers.
• Statuses. Draft, approved, part-paid, voided, written off: each needs a mapping, or a decision not to migrate it.
• Records the old system created on its own. Rounding entries, system adjustments, automatic allocations.

Map every one explicitly, and decide what happens to records that don’t fit, before writing any migration code.

Reconciliation

Agree the checks with finance before you start:

1. Trial balance at the cutover date matches between old and new.
2. Customer and supplier balances match, per contact.
3. Open invoices and bills match, individually.
4. Bank balances match statements.
5. Tax totals for the current period match.

Run them on every rehearsal, not just the final migration. More detail on layered checks is in data migration testing.

Timing the cutover

Cut over at a period end, ideally after the previous period is closed. Freeze changes in the old system for the cutover window, migrate, reconcile, and only then open the new system for new transactions. Plan for what happens to transactions that arrive during the freeze.

Keep the old system readable

Keep the old system, or an export of it, available read-only for as long as audit and retention rules require. You will need it, usually for a question nobody predicted.

The general version of this plan is the data migration checklist, and the choice between moving everything at once or in stages is covered in big bang vs phased migration. If you’re moving off a third-party platform, a migration and integration assessment maps the data and the risks before anything moves.