Migrate from Odoo Enterprise to Odoo ERP

Odoo uses res.partner for both individuals and organizations across all modules. We extract all partner records via xmlrpc or PostgreSQL direct-read, preserving address fields, category tags, bank accounts, and custom fields defined via Odoo Studio or ir.model.fields. The destination res.partner schema is matched field-for-field; no transformation is required beyond type-mapping of any custom field data types. Parent-company relationships (commercial partner linkage) are preserved via the commercial_partner_id and parent_id fields, and partner_id references on every related document (sale orders, invoices, purchase orders) are resolved at migration time.

Product templates and their variants migrate as a bundle. We preserve product.category hierarchy, vendor pricelist entries (product.supplierinfo), product routes (make-to-order, dropship via stock.location.route), and product.attribute.value combinations. Bills of Materials and work order routing data (mrp.bom, mrp.routing) are covered in the Manufacturing object. Any Enterprise-only fields (e.g., pos_categ_id from POS Enterprise) are flagged and excluded from Community-compatible imports.

Sale orders are migrated with their order lines (sale.order.line) and linked delivery orders (stock.picking) and invoices (account.move). We preserve the picking state (assigned, done, cancelled) and invoice state (draft, posted, paid) from the source so the destination picks up the order in its current status rather than resetting to draft. The sale_journal_id is remapped to the destination's chart of accounts journal. If the source uses Enterprise-specific sale type workflows, those stages are stripped and mapped to the standard sale order states available in Community.

Purchase orders migrate with their order lines, linked receipts (stock.picking), and vendor bills (account.move). We preserve receipt-to-bill matching which is critical for accounts payable accuracy; the destination account.move record carries the same reconcile linkage to the original purchase order. Picking state and invoice state are preserved. Any Enterprise-specific purchase approval workflows are excluded from migration scope.

Odoo Accounting stores posted invoices, vendor bills, and journal entries in account.move. We handle posted vs. draft records differently: posted invoices migrate with full line-item and tax mapping; draft invoices migrate for completion in the destination. Tax grid mappings and reconciliation records are preserved via account.full.reconcile and account.partial.reconcile where the destination schema supports them. We validate that the destination's tax codes can accept the source tax rates before committing the invoice batch.

Chart of Accounts entries are country-specific via fiscal localization modules. Account codes, types (receivable, payable, expense, revenue), and tax receipt tags must be mapped to the destination's country-matched localization. We use the country localization module of the destination instance to validate that each source account maps to a valid destination account code before importing. Cross-country localization migration is not attempted without explicit remapping of every affected account and tax code.

Fiscal positions map taxes and accounts based on partner country and VAT number. These are critical for EU VAT compliance and must migrate alongside every invoice and partner record. We validate that the destination's fiscal.position records have matching account.account and account.tax references in the destination localization before committing. If the destination is in a different country from the source, we flag all fiscal positions for admin review and remapping rather than attempting automatic migration.

Project and task records migrate with their full hierarchy including sub-tasks, assignees (user_ids), tags (project.tags), stage pipeline configuration, and timesheet entries (account.analytic.line) where applicable. Custom stage logic defined via Odoo Studio or automated actions is excluded from migration scope; we document the stage names and their sequence so the customer's admin can rebuild the pipeline in the destination. Timesheet history is migrated as read-only analytic line records.

hr.employee records migrate with contracts (hr.contract), attendance history (hr.attendance), leave allocations (hr.leave.allocation), and payslip history (hr.payslip) as read-only records. Employment status and effective-dated contracts are preserved with their start and end dates. Historical payslip data migrates as read-only to maintain payroll reporting continuity. If the destination uses a different country localization for payroll (e.g., country-specific HR modules), we flag payroll-related fields for admin review before import.

Odoo stores attachments in both the PostgreSQL database (ir_attachment with db_datas) and the filestore directory. We extract both sources, reconstruct the filestore tree on the destination Odoo instance, and relink database attachment records to the reconstructed filestore paths. Large attachment volumes (over 50 GB) require direct filestore extraction rather than xmlrpc transfer due to API overhead. Binary attachments are base64-encoded for transmission and decoded on the destination.

stock.quant (on-hand quantities), stock.move (transfer history), and stock.picking (picking orders) migrate with lot and serial number traceability preserved. Warehouse-specific quants are mapped to the destination warehouse configured in the destination Odoo instance. Quant snapshots are migrated as of a defined cutover date; in-transit moves are flagged for the customer's inventory team to reconcile after go-live. Stock valuation records (account.move lines tied to stock moves) are migrated only if the destination accounting localization supports the same valuation method.

Bill of Materials and work orders migrate via the mrp module models with routing operations, workcenter assignments, and consumption tracking preserved. We verify that the destination Odoo instance has the Manufacturing module installed before migration; if it does not, BoM and routing data is excluded from scope and flagged in the migration inventory. Enterprise-specific manufacturing features (such as mrp_workorder_module dependencies) are flagged as Enterprise-only and excluded.

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 relational fields (many2one, one2many, many2many), which require pre-creation of the destination custom model schema before data import. The destination custom model must be created in the destination Odoo instance first; we do not create destination schema via migration scripts. Lookup dependencies are resolved at migration time against the destination's existing record set.