Migrating legacy data into Odoo, with the consolidation done first
Odoo keeps one partner record for customers, vendors, and contacts, one product template with its variants, and one accounting move for invoices and journal entries. Legacy systems keep several of each. The work of an Odoo migration is the consolidation: which duplicates become one partner, which item codes become variants of one template, which currencies and units have to be resolved before the CSV importer or the external IDs will accept a row. Datapace maps the legacy source first, proposes each consolidation with its evidence, and has your domain expert validate it.
Today. Workbooks and legacy tables mapped into Odoo by hand, with duplicates and mixed currencies found after the first import fails.
With Datapace. The source is resolved into one map, each consolidation is proposed with a confidence score, and your expert validates the partner, product, and account decisions before the load.
What Datapace does here
- One partner, several sources
- Customer and vendor masters, contact lists, and the addresses hidden in order headers are resolved into one res.partner per real party, with the duplicates shown and the merge left to your expert.
- Templates and variants
- Item codes that differ only by size, colour, or pack are proposed as variants of one product.template, so the catalogue lands the way Odoo expects it.
- Orders and accounting moves
- Order headers and lines map to sale.order and sale.order.line; invoices and journal lines to account.move, against the chart of accounts you confirmed.
- Findings before the importer sees them
- Duplicate keys across workbooks, currency mixes, orphaned lines, and codes without a target are surfaced with their impact while the mapping is open.
- External IDs and rationale kept
- Every accepted mapping is recorded with the external ID it produces and the reason, so a re-import or a later audit has something to check against.
The target model
What the mapping resolves to. Each row is proposed with its evidence and validated by your domain expert before load.
| Legacy source | Odoo model | Decided before load |
|---|---|---|
| Customer master, vendor master | res.partner | One record per real party, customer_rank and supplier_rank set from the sources |
| Item master, price lists | product.template, product.product | Variants proposed from codes that differ by attribute only |
| Order header, order lines | sale.order, sale.order.line | Units and currencies resolved before load |
| Invoices, journal lines | account.move, account.move.line | Against the confirmed chart of accounts |
| Chart of accounts | account.account | Legacy codes crosswalked, unused accounts flagged |
Questions teams ask
- How does Datapace handle Odoo external IDs?
- Each accepted mapping records the external ID the row will carry in Odoo, so re-imports update instead of duplicating, and the audit trail ties every Odoo record back to its legacy source.
- What happens to history the client does not want in Odoo?
- The mapping marks what moves and what stays, with the reason. Open orders and active partners typically move; closed history is either summarised into opening balances or kept queryable on the validated map of the legacy base.
- Who validates a consolidation?
- The person who knows the business: the Odoo integrator for the model, the client’s domain expert for which duplicates are really one party. Datapace proposes with evidence; a person decides.
Go further
See this on your own data
Bring a use case. We will show you what Datapace reads on your live database, what your experts would confirm, and what the agents would propose first.
Book a call