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

As much as can be verified, and no more. The right cut-off is the last date the figures tie to bank statements and supporting documents, because anything earlier imports uncertainty into a system whose whole purpose is to be reliable. Two years of verified data is worth more than five years where three are unsupported.

What is a conversion balance?

The opening position entered into a new accounting system at the migration date, covering bank balances, debtors, creditors, VAT, fixed assets and equity. It is the foundation everything afterwards sits on, so it is reconciled line by line before any transactions are entered. An unreconciled conversion balance produces a ledger that never quite agrees and nobody can explain why.

What happens to the old records after a migration?

They are archived in a readable form and retained for the statutory period, with a written note of what was archived, at what date, and why the conversion point was chosen. Retention obligations do not disappear because the data was not migrated. The archive plus the explanation is what allows the decision to be defended later.

Should VAT errors be fixed before or after migration?

Before, in almost every case. Migrating known errors carries them into the new ledger and then requires correcting them twice, once in the source and once in the destination. Correcting first also means the conversion balance reflects the right VAT position, which is one of the balances most likely to be wrong in a spreadsheet-based system.

How long does a spreadsheet-to-ledger migration take?

The import itself is quick; establishing and reconciling the conversion balance is what sets the timetable. Where records are clean, this is a short exercise. Where the opening position has to be reconstructed from bank statements and source documents, that reconstruction is the project and the software is incidental to it.

SaaS · 🇬🇧 United KingdomScenario

Choosing a conversion balance date in an accounting migration

The decisive judgement in an accounting system migration is what not to bring across: the conversion balance is set at the last date the figures genuinely tie to bank statements and supporting documents, and earlier history is archived with a documented explanation rather than imported. This is an illustrative example of how Salt approaches migrations, using a UK startup moving from spreadsheets to Xero as the profile.

Ask how we'd handle this

Scenario — an illustrative example of how Salt approaches this problem. Not a description of a specific client engagement.

The business shape it describes: UK startup migrating from spreadsheets, 14 staff.

Scenario covers: Accounting system migration and ongoing bookkeeping
Software it assumes: Xero
Jurisdiction: United Kingdom
Sector: SaaS

The setup

Take a UK startup of 14 staff that has grown on spreadsheet bookkeeping and now needs a proper ledger before its next external reporting requirement.
The instinct is to migrate all the history, on the reasonable-sounding basis that more data is better than less.

What usually turns out to be wrong

Only the most recent months tying to bank statements with confidence, with earlier periods carrying gaps in source documentation that cannot be closed.
VAT calculated manually throughout, with errors in some quarters that would be imported along with everything else if the history came across unexamined.
No documented basis for several opening balances, so importing them would carry an unexplained figure into a brand new ledger.
Bank feeds available for a limited history, which sets a practical boundary on how far back the ledger can be reconstructed from primary data.

How this would be worked

Establish a verified conversion balance at the last date that genuinely ties out, rather than migrating unverifiable history because it exists.
Migrate transactional detail forward from that date, and reconcile the opening position line by line before anything else is entered.
Archive the earlier records with a written explanation of what was archived and why, so the decision is documented rather than remembered.
Correct the VAT quarters affected by the manual calculation before they are carried into the new ledger.
Move VAT preparation into the ledger, so the return is generated with an unbroken digital link rather than assembled separately.

Why we'd be the right fit

The judgement in a migration is what not to bring across. Establishing the conversion balance at the last point that genuinely ties to bank statements, and being able to document that choice, matters more than the mechanics of the import.
It also means declining what founders usually ask for, which is easier when you have had to defend a conversion position before.

What the business would be able to do

The company would open the new ledger with a defensible position rather than importing history nobody can substantiate.
The choice of conversion date would be documented, so it can be explained to a lender, an investor or an external accountant later.
VAT would be generated from the ledger with the digital link intact, instead of being calculated alongside it.

What we'd flag

Archiving rather than migrating leaves the company without comparatives for the earlier periods, which is a real cost. Carrying unverified balances forward would make the ledger look complete while being wrong, and that trade is usually worth making, but it is a trade.

Answers

Choosing a conversion balance date in an accounting migration

Where this applies

Tech Stack MigrationService BookkeepingService All services in United KingdomFRS 102 / UK GAAP More scenarios42 illustrative, labelled examples

Start with a number

Recognise this shape in your own books?

Tell us where you trade and what shape the books are in. You get scope, price and a start date in writing within one business day — no obligation.

Get a quote in 24 hoursBook a call instead