Migrate your Odoo ERP data

Partners is Odoo's primary contact object. It uses External IDs (e.g. base.us) for cross-reference in imports. We preserve partner categories, addresses, and bank details and map them to the destination CRM's contact schema.

Products include name, type (stockable/consumable/service), list price, standard cost, and variants via attribute combinations. We handle the product.supplierinfo relation for vendor pricing and preserve images via public URL during import.

Stock quants track on-hand quantities per location. We map warehouse locations to destination inventory locations, but lot/serial number traceability may require manual verification post-import due to destination schema differences.

Sales Orders link to Partners and Products with order lines. We preserve the full order lifecycle (draft → confirmed → done) and map fiscal positions that affect tax computation on the destination system.

Odoo 17+ unified invoices into account.move with move_type (out_invoice, out_refund, etc.). We map to destination invoice records but flag posted invoices as non-editable — they require credit notes for corrections rather than in-place edits.

Accounts are tied to fiscal positions and taxes by country. We map the account codes and names, but country-specific tax groups and fiscal position rules require explicit configuration in the destination ERP post-migration.

Projects in Odoo have a task hierarchy and can belong to multiple stages. We preserve project stage pipelines and map task assignees using Odoo's many2one user reference format.

Tasks link to Projects, include sub-tasks (parent_id), and track stage, assignee, and deadline. We preserve the task hierarchy and map custom stage names to destination stage pipelines.

MOs reference Bills of Materials (BoM) with component lines and workorder sequences. We map the BoM structure and MO states, but workorder routing dependencies may require re-sequencing in the destination system.

BoMs define product components and quantities. We preserve the product structure and type (kit, manufactured, phantom), but variant-specific BoMs require mapping to destination product variant IDs.

Employees are in the hr.employee model and linked to Users. We map employee records but note that Employee categories, emergency contacts, and HR-specific fields are Odoo-specific and may not have a direct destination equivalent.

Odoo allows custom fields via Settings → Technical or ir.model.fields. Custom fields added by Odoo Studio are stored with ttype and may have selection options. We preserve custom field definitions and values, but field types not supported by the destination system fall back to text.

Attachments (ir.attachment) store files in binary or as URLs. Large binary attachments should be provided as public URLs for Odoo to download at import time rather than uploaded directly via CSV.

Odoo defines taxes with scope (sale/purchase), tax_type (percent, fixed, group), and country-specific fiscal positions. We map tax names and rates, but fiscal position automation requires destination-side configuration.