Odoo migration workbook for UK finance and operations data

Reviewed 5 November 2026. Use this workbook as the controlling structure for a UK Sage, Xero or multi-system Odoo migration. It is designed for repeated trial runs and final cutover. Create one controlled record for every data object and retain the evidence produced by each run.

1. Set migration governance before extraction

Name the migration lead, client data owner, source-system owner, target-solution owner, import operator and reconciliation approver. These can be different people for different objects, but every responsibility must be explicit.

Agree the cutover moment, source freeze rules, history policy, archive route, environment access, sensitive-data handling and decision route for exceptions. Record which finance, operations and tax specialists must approve particular mappings or balances.

The migration register is part of the programme baseline. Changes to objects, history depth, mapping rules or acceptance levels are assessed through change control because they can alter effort, dependencies and release readiness.

AI assistance can help inspect values or suggest transformations, but it does not assign business meaning or approve financial outcomes. Named people remain responsible for every rule and reconciliation.

2. Create one object-register entry per dataset

Use a separate entry for each company-specific or logically independent dataset. Do not group every finance table into one line called “opening data”.

• Object ID and business name: Assign a durable reference such as a source-company and object combination, using the organisation's own naming convention.
• Source and target: Identify the exact system, company, export or API resource and the intended Odoo model, document or configuration area.
• Business owner and technical owner: Name who understands the records and who can operate the extraction and target mechanism.
• Selection rule: State which companies, statuses, dates, history periods and record types are included or excluded, and why.
• Target purpose: Explain whether the data supports operations, opening balances, reporting, compliance, audit or archive access.
• Quality assessment: Record duplicate patterns, missing mandatory values, obsolete codes, inconsistent units and known source limitations.
• External-ID rule: Define the durable source namespace and identifier used on every rerun.
• Dependency position: Name every object or configuration that must be accepted before this object loads.
• Reconciliation method: Define source and target reports, counts, control totals and the detail level at which differences will be investigated.
• Acceptance owner: Name the person who signs the business result after technical loading and reconciliation are complete.

A dataset with no clear target purpose is a candidate for a controlled archive rather than an operational import. That decision should be documented rather than made implicitly by leaving it out of a file.

3. Control source extraction

Preserve an untouched copy of every authoritative source extract. Use a naming convention that identifies source system, company, object, cutover moment and extraction sequence without embedding sensitive values in the filename.

Record the extraction method, filters, user, date and time, source report parameters and any documents still unposted. Include the source row count and control totals before transformation. If the source provides separate headers and lines, record the relationship and expected line count as well.

For Sage environments, identify the exact product and version because structures and exports differ. For Xero, identify the organisation and connected apps that may hold additional operational data. For banks, preserve statement exports and the account, currency and statement period they represent.

Do not edit the preserved source file to make a problem disappear. Apply corrections in the source system where appropriate, or in a versioned transformation with a logged exception and owner.

4. Maintain a cleansing and exception log

Every cleansing action should be traceable. Record the object, source identifier, issue, business decision, person making the change, evidence and whether the correction must also be made in the source system before final extraction.

Typical decisions include merging duplicate customers or suppliers, archiving obsolete items, standardising addresses, assigning missing tax codes, correcting units of measure, resolving invalid account mappings and identifying unbalanced source documents.

Separate a genuine source correction from a target default. A default tax, account, warehouse or currency can change financial meaning and requires an authorised owner. Avoid using a generic “unknown” value to make mandatory validation pass unless that value has an approved reporting and follow-up treatment.

Re-run quality checks after cleansing. The exception log should show both resolved items and any consciously accepted residual issues, including their operational impact and follow-up owner.

5. Complete the mapping register

The mapping register connects business meaning to the target design. Keep it under version control alongside the transformation and test evidence.

For each target field or related record, document the source field, transformation, mandatory status, default authority, validation rule and example of expected behaviour. Include account type, currency, tax, payment terms, analytic dimensions, item type, costing, units, warehouses and approval fields where relevant.

Map source identifiers to stable target external IDs before loading dependent records. If several source records merge into one target, retain every source-to-target relationship. If one source record splits, document the rule and control totals that prove nothing was lost.

Record deliberately unmapped fields. This prevents a later reviewer from wondering whether a forgotten value was dropped accidentally. Where the target does not need a source field, state the reason.

Process owners approve the mapping for their area. Finance approves accounting and tax mappings, operations approves stock and fulfilment mappings, and integration owners approve identifiers shared with external systems.

6. Use durable external IDs and idempotent reruns

An external ID should derive from a stable source identifier within a source-company namespace. Names, email addresses, invoice numbers and spreadsheet row positions can change or collide and should not be the sole identity mechanism.

Define what happens when an external ID is loaded again: update permitted fields, skip an already accepted record, or raise a conflict for review. Never allow a rerun to create an accidental duplicate because a name or formatting value changed.

Keep the external-ID strategy consistent across master data and documents. Dependencies should resolve through those identifiers rather than through a newly generated target sequence that changes between test environments.

Idempotence does not mean that every field must be overwritten on every run. Accepted manual changes in the target may need protection. The rule for each object should say which system owns each field after cutover and how later corrections are handled.

7. Sequence imports by dependency waves

Build a dependency graph and express it as ordered waves. The exact sequence depends on the solution, but the reasoning should be visible.

• Wave 1 — foundation: companies, currencies, users or access prerequisites, accounts, taxes, journals, analytic structures, payment terms and other accepted configuration.
• Wave 2 — independent masters: customers, suppliers, contacts, addresses, products, services, units, warehouses, locations and projects whose prerequisites are complete.
• Wave 3 — dependent masters: pricelists, bills of materials, routes, bank details, integration mappings and records that combine earlier masters.
• Wave 4 — operational documents and positions: open orders, invoices, bills, credit notes, stock quantities and valuation, project balances and other open work.
• Wave 5 — financial completion: opening entries, payments, allocations, bank statement lines and reconciliations that depend on all preceding records.
• Wave 6 — history and evidence: closed transactions, attachments and archive links where these are deliberately included after the operational position is proven.

A later wave does not start merely because file preparation is complete. Its prerequisites need their own technical and business acceptance. This prevents cascading errors that are expensive to untangle.

8. Record every trial import as a repeatable run

For each run, retain the mapping version, transformation version, source-extract identifiers, target environment, operator, start and finish events, wave results and exception log. The aim is to reproduce the run, not to remember a sequence of manual clicks.

Record expected counts, attempted counts, created counts, updated counts, skipped counts and failed counts for each object. Explain every difference. A zero technical error count is useful only when all expected records have also been accounted for.

After a failure, correct the source, mapping or configuration through the appropriate owner and rerun the controlled process. Verify that existing records are updated or skipped as designed and that no dependent duplicate was created.

Use the same procedure for mock go-live and final cutover wherever possible. A last-minute manual shortcut invalidates part of the rehearsal and should trigger a new assessment of readiness.

9. Reconcile both financial and operational outcomes

Choose reconciliation reports before loading so the expected evidence is not shaped around whatever the import happened to produce.

Finance commonly needs trial balance, aged receivables, aged payables, bank balances, tax control and currency positions at the same cutover moment. Stock operations may need quantity and valuation by product and location, plus lots or serial numbers where used. Projects and services may need open budgets, uninvoiced work and milestone positions.

Compare source and target at the detail level needed to find the cause of a difference. Control totals alone can hide offsetting errors. Investigate account, tax, partner, currency and date differences with the relevant owner.

Bank history requires boundary checks between statement imports and live feeds. VAT-related records require the accountant-approved mapping and a check of their effect on the intended VAT100 workflow. UK localisation structures in Odoo 19 do not make migrated treatment correct automatically.

The acceptance report records the source baseline, target result, differences, resolutions, residual approved items and sign-off. A migration-clearing or suspense balance is not an acceptable substitute for explanation.

10. Rehearse cutover and close migration formally

A mock go-live uses the complete runbook with representative final extracts and the actual operators. Test source freeze, final extraction, dependency waves, integration switching, user access, reconciliation and operational smoke tests. Use a production copy where appropriate and controlled.

Record waiting time and decision points as well as import execution time. The rehearsal informs sequencing and resource planning; it does not create a promise of total project duration.

The final runbook identifies the go or no-go authority, critical failures, correction and rerun route, fallback decision and communication path. Hypercare includes data exception triage and operational reports that reveal whether migrated records are being used correctly.

Close each object only when its import is repeatable, reconciliation is accepted and future ownership is clear. Retain source extracts, mappings, external IDs, logs, exception decisions and sign-offs under the organisation's access and retention controls.

Educational sources and official references

This workbook applies delivery practices discussed in the public OXP2026 sessions on migration and import practice, data dependencies and implementation operations, implementation responsibilities and testing and readiness. They are educational sources only and are not Oakland customer references.

For UK product boundaries, use the Odoo 19 United Kingdom localisation guide and Odoo 19 bank synchronisation guide. For MTD digital records and links, use HMRC VAT Notice 700/22. These official sources and the organisation's own evidence take precedence over generic migration assumptions.