Moving data into Odoo is a controlled change to business records. Start by agreeing which records belong in the new system, how they map and what evidence will show that the result is acceptable.
An Excel file, a QuickBooks export and a Tally export can contain different structures and business meanings. A successful upload does not establish that accounts, stock, tax treatment or relationships are correct. This guide sets out a migration plan to assess with your data owners; it does not promise a loss-free transfer or prescribe a universal retention period.
Choose the scope before exporting everything
Create a migration register with a row for each proposed dataset. Record its business owner, source, intended target, period covered, dependencies and acceptance checks. Separate master records, opening positions, open transactions and historical transactions. Not every old record needs to be recreated in the new operational database.
Decide what must remain accessible in a read-only archive and who will maintain that access. Retention periods, audit evidence and accounting treatment depend on your obligations and circumstances; confirm them with the responsible adviser. A generic “keep two years” rule is not a sufficient retention policy.
| Dataset to assess | Questions before mapping | Possible acceptance evidence |
|---|---|---|
| Customers and suppliers | Which records are duplicates? Who owns identifiers and contact updates? | Approved record counts and sampled relationships. |
| Products and units | Are product codes unique? Are units and categories consistent? | A code-to-code mapping and checks of selected products. |
| Opening financial positions | Which date and accounting approach are approved? How do open items relate to balances? | Agreed control totals and reviewer acceptance. |
| Stock and valuation | Which locations, quantities, costs and valuation rules are in scope? | Reconciled quantities and values, with explained differences. |
| Historical records | What must be operational, and what can remain in an archive? | Retrieval checks and confirmed access responsibilities. |
Build a field and relationship map
For each field, record its source meaning, target field, transformation rule, required values and owner. Check dates, decimal formats, currencies, units, codes and missing values in representative samples. Do not silently turn a missing value into an invented default.
Relationships matter as much as individual rows. An order line must refer to the intended product and parent transaction. Odoo’s import documentation explains that related records need to exist before the records that reference them. Work out the dependency order for the actual models being imported.
Use stable external identifiers where appropriate and preserve the mapping. Odoo documents External IDs as a way to recreate relationships and update records on later imports. Changing or removing those identifiers can create duplicates during an update. A matching name alone may be ambiguous when several records share it.
Trial the import in a separate environment
Confirm the intended Odoo version, edition, hosting and permitted import or development route first. Prepare a trial environment with access limited to the people who need it. Use anonymised samples where they can answer the question, and agree a secure route before transferring any production data.
- Take a small sample containing ordinary records and known exceptions.
- Confirm the target configuration and mapping before loading dependent records.
- Use the import tool’s Test step to identify validation problems.
- Investigate rejected rows and ambiguous matches; record corrections.
- Import the approved trial sample, then check the resulting records and workflows.
- Repeat only with a controlled identifier strategy and an understood effect on existing records.
The Test step checks validity for the tool; it is not a substitute for business reconciliation. Odoo also warns that imports are permanent and cannot simply be undone. Agree backup and recovery arrangements before any production load. Do not assume a second upload, a delete action or an “undo” button restores the previous operational state.
Reconcile meaning, not just record counts
Set expected results before the trial. Counts help identify missing or duplicated rows, but equal counts can still conceal the wrong relationships, amounts or status. Combine control totals with sampled records and end-to-end workflow checks relevant to the scope.
- Compare agreed financial totals and open items without double counting opening positions.
- Check quantities and values by the relevant product and location boundaries.
- Review sampled links between customers, documents, products and payments.
- Test an ordinary business transaction and an exception using the imported records.
- Confirm role-based access and the reports the business reviewer will use.
Log each difference with its expected result, actual result, cause, owner and disposition. A reviewer may accept a documented rounding treatment or an out-of-scope historical field, while a different mismatch blocks release. Make that an explicit decision, not an unexplained adjustment to make totals look equal.
Agree cutover and recovery responsibilities
The cutover plan should name the data freeze or final-extract point, permitted activity during the transition, final transformations, load sequence, validation checks and release decision maker. Confirm who can access backups and how recovery would be evaluated if the final checks fail.
A parallel run may be useful for some workflows, but it creates its own ownership and reconciliation work. Define where each transaction is entered and how duplicate posting is prevented. There is no blanket requirement to run every project in parallel for a full month-end; choose the approach with the business owners and advisers.
Recovery after new transactions have been recorded is different from recovery before opening the system to users. Decide how those transactions would be preserved or reconciled. Do not present rollback as a guarantee that every later change can be reversed without loss.
What should the handover contain?
Retain the approved mapping, transformation rules, identifier register, trial results, exception log, final reconciliation and release decision. Assign responsibility for the archive, future data corrections and support questions. Train the relevant users on changed fields and workflows, including how to recognise and report a data issue.
For an illustrative wholesaler, a sample might include two products with similar names but different codes and an order with insufficient stock. That fictional test reveals why matching by name alone is weak. It does not demonstrate that a particular customer migration succeeded.
Review Tenxora’s Odoo data migration and cutover service or book an introduction to discuss scope. No fixed transfer duration or guaranteed opening-day match is implied; acceptance depends on the agreed evidence.
Sources and editorial note
Primary technical reference: Odoo 19: importing and updating data. Use documentation matching your actual version and environment. The register, reconciliation prompts and cutover checklist above are Tenxora’s proposed planning approach.
The earlier version cited the Ecosire migration guide, Candidroot’s timeline article and an Odoo community discussion. Attribution remains; this revision replaces blanket timing and retention rules with project-specific decisions. Editorial update: 3 November 2026. No external expert review is claimed.
