Migrating historical accounting data

The general problem of ERP migration is covered in migrating to an AI-native ERP. This is the narrower accounting question: what happens to your ledger history, and how much of it needs to come with you.

The answer is less than people assume, and the decisions are more consequential than they look.

How much history to bring

Three different things are frequently conflated.

Opening balances. Non-negotiable. Every balance sheet account, decomposed into the items that make it up — individual debtors, individual creditors, individual unmatched items. Not a total.

Transaction history. Useful rather than essential. Its value is that it teaches the system your coding patterns, which is what makes automated coding useful from day one rather than month three. One to two years is the useful range, and beyond that the return falls sharply because older patterns may no longer reflect how you operate.

Documents. Governed by retention obligations rather than by system convenience. These do not have to live in the new system — but they have to live somewhere retrievable for the whole retention period, and "somewhere" needs deciding rather than assuming.

The common mistake is treating all three as one requirement and attempting to move fifteen years of everything. That is expensive, slow, and imports fifteen years of inconsistency into a system that will learn from it.

The balances that will not decompose

Every migration meets this. A control account balance that does not break into nameable items — an old debtors figure containing amounts nobody can attribute, a suspense balance carried for years, an accruals account with unreversed items.

Three options, in order of preference:

Investigate and resolve. Correct where it belongs. Best answer, and worth real effort for anything material.

Write off, with a decision and a record. Someone senior decides, the reason is documented, and it happens before migration rather than after. This is a legitimate answer for old immaterial items and it needs to be a decision rather than a drift.

Migrate it as-is. The worst option, and the most common. The unexplained balance moves to the new system, where it is now unexplained and has no history attached, because the system that might have explained it has been decommissioned.

Do not migrate a balance you cannot explain. Once it crosses, the ability to investigate it goes from difficult to effectively impossible.

The decision about the old system

Businesses routinely decommission the old system too early, and it is the mistake with the longest tail.

Your retention obligations outlast the migration. If a question arises about a transaction from three years ago and the detail lives only in a decommissioned system, you have a records problem that no amount of preparation in the new system fixes.

Before switching off:

• Export everything, in a format readable without the old vendor's software. Test that it actually opens.
• Keep read-only access for a period if the licensing allows — a year is a reasonable minimum, spanning at least one full audit cycle.
• Verify the export contains the detail, not just balances. Transaction-level, with documents where they were held there.
• Check what did not come across. Attachments, notes, approval records and audit trails are the usual casualties, and they are frequently the parts you would want.

That last one matters most. The transactions almost always migrate; the context around them frequently does not, and its absence is discovered years later when someone asks why something was treated as it was.

Reconciling the migration

The check is straightforward and it must be done before the old system goes read-only:

Every balance in the new system agrees to the old system, and decomposes into the same items.

Not just trial balance totals. Debtors should contain the same individual invoices; creditors the same individual bills; stock the same quantities. A migration that ties at total level and differs in composition will produce reconciliation problems for months, and the cause becomes progressively harder to find.

Run it, sign it off, keep the reconciliation. It is the first thing an auditor asks for in a year of migration.

What not to bring

Dead accounts. The migration is the natural moment to close them — see preparing your data before automating.

Duplicate master records. Merging is easier before migration than after, because there is no new history attached yet.

Inactive customers and suppliers. Anything with no transactions in two years.

Old unmatched items you have decided to write off. Write them off in the old system, so the reason and the decision sit with the history that explains them.

The realistic sequence

1. Clean the data in the old system
2. Resolve or write off what will not decompose
3. Agree how much history to bring
4. Migrate opening balances and the agreed history
5. Reconcile — balances and composition
6. Run parallel for one period
7. Export everything from the old system and verify the export opens
8. Keep read-only access for at least an audit cycle
9. Only then decommission

Steps seven and eight are the ones under time pressure to skip, and they are the ones you cannot revisit.

Migration is also one of the few moments someone has to articulate every rule out loud in order to rebuild it — a rare, cheap opportunity to capture why each one exists, not just what it does: why it has always been done this way survives automation.

Common questions

How much accounting history should be migrated to a new system?

Opening balances must come across in full and decomposed into individual items. One to two years of transaction history is the useful range, because its purpose is teaching the system your coding patterns and older data may no longer reflect how you operate. Documents are governed by retention obligations rather than system convenience and can live elsewhere, provided somewhere retrievable has actually been decided.

What should be done with a balance that will not decompose?

Investigate and resolve it where material, or write it off with a documented decision by someone senior — and do either before migrating rather than after. Carrying an unexplained balance into a new system is the worst option, because it arrives unexplained and without the history that might have explained it once the old system is decommissioned.

When can the old accounting system be switched off?

After everything has been exported in a format readable without the old vendor's software and that export has been opened and verified, after balances and their composition have been reconciled between systems, and after read-only access has been retained for at least a full audit cycle. Retention obligations outlast the migration, and the transactions usually migrate while the surrounding context — attachments, notes, approval records — frequently does not.

What is the most common migration mistake?

Reconciling only at total level. A migration where the trial balance ties but the composition differs — different individual invoices making up the same debtors figure — produces reconciliation problems for months, and the cause becomes progressively harder to trace as new transactions accumulate on top.

Related: preparing your data before automating · record retention when records are generated · migrating to an AI-native ERP