Xero Data Migration Guide: Planning, History and Reconciliation

A Xero data migration is not simply an export-and-import exercise. The important decisions are what accounting history needs to remain usable, how the source structure should translate into Xero, and how the final organisation will be reconciled back to the old system.

This guide explains the practical stages we use when planning historical migrations from systems such as Sage 200, Sage 50, Sage Intacct, Access Dimensions, Access Financials, Business Central, Dynamics NAV, Exchequer, Twinfield and other accounting platforms into Xero.

1. Decide what the migration needs to achieve

Start with the finance team's requirements rather than the migration tool. A business that only needs a clean opening position has a very different project from one that needs several years of invoice, bill, payment, journal, VAT and foreign-currency history available inside Xero.

Before extraction, agree the cut-off date, entities in scope, years of history, currencies, reporting dimensions, attachments and any restructuring required. This becomes the migration scope against which the finished Xero organisation can be checked.

2. Choose between opening balances and historical data

An opening-balance migration brings the position forward at an agreed date. A historical migration rebuilds the accounting activity behind that position. Neither approach is automatically right for every business, but the choice should be deliberate.

Historical data can be particularly useful when finance teams need transaction-level comparatives, aged-ledger context, customer and supplier history, VAT evidence or continuity for management reporting. Opening balances can be appropriate where old detail does not need to remain operational in Xero.

It is also important to make this decision before go-live. Once a live Xero organisation has moved forward from opening balances, adding a large body of earlier history later can become a much more complicated exercise.

3. Understand the source system before designing Xero

Different accounting systems store and expose information differently. Nominal codes, departments, cost centres, projects, allocations, tax detail, document references and foreign-currency information may not have a direct one-for-one equivalent in Xero.

That is why the extraction route matters. We first establish what information is available, how reliable it is and which reports or source records will be used for reconciliation. The destination structure should not be designed in isolation from the source data.

4. Design the destination structure

A migration is an opportunity to decide what should be preserved and what should be simplified. The Chart of Accounts may need mapping or restructuring. Departments and cost centres may need to become Xero Tracking categories. Contacts may need cleaning or consolidation. Legacy codes that only made sense in the old system may no longer be useful.

The aim is not to force the old system into Xero. It is to preserve the accounting meaning while creating a structure that works properly in the destination.

5. Map the accounting logic, not just the columns

Data mapping covers more than matching field names. We consider how invoices, bills, payments, journals, credit notes, allocations, VAT, currencies and control-account behaviour should be represented in Xero.

This is where many apparently simple migrations become more technical. A file can import successfully and still be wrong from an accounting perspective. The test is whether the resulting ledgers and balances behave as expected and can be reconciled.

6. Use a trial migration before final go-live

For complex historical projects, a trial organisation gives the finance team a controlled place to review the migrated structure and data before the final cut-over. It is where mapping questions, unexpected source behaviour and presentation issues should be found.

Reviewing the trial is not just about clicking through a few transactions. The team should check the Chart of Accounts, contacts, tracking, invoice and bill detail, aged positions, tax treatment, foreign currency where relevant and the reports they will rely on after go-live.

7. Reconcile the migration back to the source

A completed import is not the same as a completed migration. Reconciliation is what demonstrates that the destination reflects the agreed source position.

Depending on scope, this can include Trial Balance comparisons, control accounts, aged receivables and payables, VAT or tax positions, bank balances, foreign-currency balances and documented exceptions. Where data has been restructured, the reconciliation also needs to explain how the old structure relates to the new one.

8. Plan the cut-over and final migration

Once the trial has been reviewed and the mapping agreed, the final migration can be planned around the cut-off. For groups, this also means deciding the entity sequence, responsibilities and how the finance team will continue operating while companies move across.

A controlled cut-over should make it clear which system is authoritative at each point, what activity needs to be captured after the trial extract, and when users should begin processing in Xero.

9. Know what may remain outside Xero

Not every piece of source-system data belongs in the accounting migration. Stock movement history, operational modules, old purchase orders, sales orders, bespoke workflow records and other system-specific information may need a different treatment or archive.

Identifying those exclusions early avoids a common problem: assuming that because information exists in the source system it must have an equivalent destination in Xero.

10. Validate the first period after go-live

The migration does not stop at handover. The first bank reconciliations, VAT return and management reports are useful checkpoints because they test the migrated structure in normal finance operations.

Training and post-migration support are particularly valuable when the destination structure has changed, because users need to understand not only where the data went but how the new accounting model should be used.

What should a good Xero migration leave behind?

A good migration should leave more than populated screens. The finance team should have a usable Xero organisation, an understood mapping from the old structure, reconciliation evidence, documented exceptions and confidence about what was and was not migrated.

If you are comparing providers or approaches, ask how the historical data will be validated, what evidence will be supplied, how source-system differences are handled and when your team gets to review the result.