Migrate your Odoo Enterprise data

Odoo uses 'res.partner' for both individuals and organizations. The External API exposes all standard fields including address, category, bank accounts, and custom fields. We map Contacts to the destination's equivalent (Accounts or Contacts) preserving tags and categories.

Product variants, templates, vendor pricelists, and routes (make-to-order, dropship) are stored in product.product and product.template. We migrate the full BoM and routing data where applicable, handling multi-attribute variant chains correctly.

Sale orders include linked records: Order Lines, Delivery Orders (stock.picking), and Invoices. We migrate these as a bundle preserving the parent-child relationships and picking/invoice state, or migrate orders only if the destination does not handle fulfillment.

Purchase orders link to suppliers, products, receipts (stock.picking), and vendor bills. We preserve the receipt-to-bill matching which is critical for accounts payable accuracy in the destination ERP.

Odoo Accounting stores fiscal positions, tax grid mappings, and reconciliation records. Open invoices, paid invoices, and journal entries all carry different migration value. We handle posted vs. draft state distinction and skip reconciliation records where the destination has a different matching engine.

Accounts are country-specific via fiscal localization modules. Account codes, types, and tax receipt tags must be mapped to the destination's country-specific Chart of Accounts. We preserve account codes but flag any tax codes that lack a direct destination equivalent.

Project.project and project.task contain sub-tasks, assignees, tags, timesheets, and stage pipelines. We migrate all task hierarchies and stage configurations, though custom stage logic (automated actions on stage change) must be rebuilt at the destination.

hr.employee records include contracts, attendance, leave allocations, and payslip history. We preserve employment status and effective-dated contracts. Historical payslip data migrates as read-only records in most destinations since payroll engine recomputation is destination-dependent.

Custom models created via Odoo Studio or ir.model.fields are fully accessible via xmlrpc://model/fields_get and standard CRUD endpoints. We migrate custom model records with all field types including many2one, many2many, and selection fields, mapping relationship targets to the destination.

Odoo stores attachments in both the PostgreSQL database (ir_attachment with db_datas) and the filestore directory. We extract both, reconstruct the filestore tree, and relink attachments to their original records in the destination. Binary attachments in the database are migrated as base64 blobs.

Fiscal positions map taxes and accounts based on partner country/VAT. These are critical for EU VAT compliance and must be migrated alongside invoices. We validate that the destination's tax codes can absorb the mapping rules; if not, we flag the mismatch for manual review.

Bill of Materials and work orders are fully migrated via the mrp module models. Routing operations, workcenters, and consumption tracking are preserved. We flag any还未 supported by the destination ERP's manufacturing module.

POS sessions, orders, and payments are stored in pos.order and pos.payment. Enterprise POS has additional features (loyalty, electronic scale integration) not present in Community or many destination ERPs. We migrate orders and payments but note that POS-specific loyalty points and closed-session reconciled data may require post-migration adjustment.

stock.quant (on-hand quantities), stock.move (history), and stock.picking (transfers) are migrated. We preserve lot/serial number traceability and warehouse-specific quants. Quant snapshots are migrated as opening balances rather than a full move history to keep migration volume manageable.