Odoo Data Migration Checklist: Map, Test and Reconcile

List data domains before selecting individual fields: customers, suppliers, products, units of measure, price lists, bills of materials, chart of accounts, opening balances and open transactions. For each domain, record why it is needed in Odoo, the period it covers and the team that owns its meaning. Separate data required for operations from history retained only for reference.

Avoid assuming that the new ERP must contain every historical record. Archived access to the legacy system or a controlled reporting store may serve some requirements more safely. Reducing scope can improve quality and rehearsal time, but the decision must consider legal retention, audits, service history and user access. Document exclusions so they do not reappear as surprises during acceptance testing.

Measure what is actually in the source. Count records, identify null and duplicate values, inspect inactive items, and test whether supposedly unique codes are truly unique. Check relationships such as products without categories, contacts linked to missing companies and transactions that reference archived accounts. A source profile turns vague concern about “dirty data” into a list of observable conditions.

Include business users in the review because technical consistency does not guarantee business correctness. Two customer records may be valid subsidiaries rather than duplicates; an unused unit of measure may be required for seasonal work. Record cleanup rules, exceptions and ownership. Wherever possible, correct data at the source so repeated extracts do not reintroduce the same problem.

A mapping specification should describe more than source and destination field names. Include transformations, defaults, lookups, relationship order, ownership and validation rules. Note where several source values become one Odoo value or where one overloaded legacy field must be separated. For accounting and inventory data, state the expected effect on balances and valuation.

Use stable external identifiers so related records can be loaded and updated predictably across rehearsals. Decide how archived records, attachments, multilingual values and custom fields will be treated. Mappings should be reviewed by someone who understands the source and someone who understands the target process. This is where differences in business meaning are safest to resolve.

Plan the sequence around relationships. Reference data and configuration normally precede companies, contacts and products; master records precede open transactions; and opening positions are loaded only after their supporting structures are ready. The precise order depends on the solution, but it should be written down and automated enough to repeat consistently.

Keep extraction, transformation and import steps separate where practical. Store source snapshots securely, version mapping logic and retain import logs. If a load fails, the team should know which records were accepted, which were rejected and how to restart without creating duplicates. A repeatable process is more valuable than a one-off import that succeeds only on the original developer’s machine.

Begin with a representative subset to prove mappings and relationships, then progress to full-volume rehearsals. Small samples can hide performance limits, duplicate behavior and late failures. Use the same environment assumptions, sequence and validation steps intended for cutover, and record how long extraction, transformation, loading and reconciliation take.

Each rehearsal should have a defined objective and exit criteria. Early runs may focus on structural correctness; later runs should prove completeness, duration and business usability. Track recurring errors instead of fixing them manually inside the target. A successful rehearsal is one the team can explain and repeat, not simply a database that appears populated.

Validation needs several layers. Compare source and target record counts, totals by company or period, inventory quantities and values, receivable and payable balances, and the status of open documents. Investigate expected differences and document their causes. Automated reconciliation reports are useful, but they should not be the only evidence.

Ask process owners to find known customers, products and transactions, then complete realistic work using the migrated data. They may uncover misleading descriptions, unusable categories or missing relationships that aggregate totals cannot reveal. Record sign-off by domain so accountability is clear and unresolved issues have an owner and assessed impact.

Define when users stop changing the old system, how the final extract is secured and how late transactions are handled. The cutover runbook should include the exact sequence, owners, credentials, expected duration, validation checkpoints and communications. Establish the conditions for proceeding, delaying or returning to the previous system before the team is under time pressure.

Retain approved source extracts, mapping versions, import logs, reconciliation results and sign-offs according to your security and retention requirements. After launch, monitor the first full operating cycles and restrict ad hoc corrections that bypass ownership. A well-controlled migration leaves a traceable explanation of what moved, how it changed and why the business accepted the result.