Xero to Odoo migration: connect finance to operations

A Xero to Odoo programme is usually justified by an operating requirement rather than dissatisfaction with a ledger screen. Purchasing approvals, landed costs, stock control, projects, manufacturing, multi-entity processes or management reporting may have outgrown a collection of separate apps. Discovery identifies which of those needs belongs in Odoo and which connected products should remain.

Document every Xero organisation, base currency, VAT registration, bank account, tracking dimension, user role and connected app. Include spreadsheets that form part of the accounting or operational record. They may reveal a digital-link dependency, a migration source or a manual control that the future design must replace deliberately.

The target baseline for current capability statements is Odoo 19. Odoo 20 announcements and event demonstrations are not counted as current Odoo 19 capability. Prototype the actual future workflow in the version proposed for the engagement.

Every imported record receives a stable external ID that includes the Xero organisation namespace and a durable source identifier. A contact name, invoice number or spreadsheet row number alone is not a safe identity. Where duplicate contacts must be merged, retain the mapping from every source identifier to the approved target.

The mapping register identifies the target object, mandatory fields, transformation, defaults, dependencies and acceptance report. Account types and tax behaviour require finance review. Contact addresses, VAT references, payment terms and bank details require business review. Item types, units, costing and warehouse settings require operations review where they apply.

Opening balances are loaded after foundation records have passed acceptance. Reconcile the trial balance to the same cutover moment as aged receivables, aged payables, bank balances and stock positions. Investigate differences at source rather than posting an unexplained balancing figure.

Open invoices and bills must reproduce the amounts, currencies, dates, tax treatment and outstanding allocations needed for future collection, payment and VAT work. Part-paid documents and credit notes receive explicit test cases. Any residual manual adjustment has a named owner, reason and approval.

Trial imports use versioned source extracts, controlled mappings and a documented dependency order. Foundation records come before parties and items; those masters come before open documents; balances and allocations follow their prerequisites. Rerunning a corrected file must update or deliberately skip known external IDs rather than create another set of records.

Each run produces counts, errors, exceptions and reconciliation results. Business owners sign off the meaning of the data while the migration operator confirms technical repeatability. AI tools may help inspect or transform data, but they do not approve mappings or financial outcomes.

A mock go-live exercises final extraction, cleansing cut-off, imports, integration switching, user access, HMRC-related checks, reconciliation and operational smoke tests. The real cutover runbook then records freeze rules, delta handling, decision authority, fallback and hypercare ownership. A technically complete load without accepted business outcomes is not a successful go-live.