Migrate from Odoo ERP to Microsoft Dynamics 365 Business Central

Odoo Partners (res.partner) serve as both contacts and companies in a single record with type flags (customer, vendor, employee). Dynamics 365 splits these into separate Contact and Customer/Vendor entities. We extract the partner name and addresses into Dynamics Contact records and the commercial relationship into Customer or Vendor records. Multi-address per partner (billing, delivery, other) maps to separate Contact addresses with distinct Address Type codes. Partner categories map to a Customer Group or Vendor Group lookup that we pre-configure before migration.

Odoo product.template with product.product variants maps to Dynamics Item with variant tracking via the Item Variant Code or Item Cross Reference entities. We preserve the product type (stockable, consumable, service) and map the list_price and standard_cost to Unit Price and Standard Cost on the Item. Vendor-specific pricing in Odoo product.supplierinfo maps to Vendor Catalog entries in Dynamics. Attribute combinations on the source product.template generate separate variant records that we map to Dynamics Item Variants with matching Variant Code values.

Odoo stock.quant tracks on-hand quantity per location (stock.location hierarchy). We map the source warehouse locations to Dynamics warehouse codes in the InventLocation table and create Item Ledger Entries reflecting the on-hand quantity at migration cutover. Lot and serial number traceability migrates to Item Tracking Code assignments and Item Tracking Legend entries, but customers must verify lot/serial counts manually post-import because Dynamics requires explicit Item Tracking Code configuration before any tracked inventory can be received.

Odoo Sales Orders map to Dynamics Sales Header records. The order state (draft, confirmed, done, cancel) maps to the Dynamics Document Status (Quote, Order, Released, Cancelled). Odoo order lines map to Sales Line records with product references resolved to Item numbers, quantities preserved, and unit prices transferred from the source order. If Odoo fiscal positions affect tax computation on the source order, we replicate the tax group assignment on the destination sales line to maintain tax correctness at migration.

Odoo 17+ unified invoices into account.move with move_type distinctions. We map posted out_invoice records to Dynamics Sales Invoice Header, posted out_refund records to Sales Cr. Memo Header, and posted in_invoice records to Purchase Invoice Header. Posted invoices are non-editable in Dynamics 365; we do not attempt to re-import or adjust them after posting. We preserve the Odoo invoice number as the External Document Number and the Odoo invoice date as the Posting Date. Any posted Odoo invoice with a partial payment history must be reconciled by the customer's accountant post-migration against the payment journal entries.

Odoo Chart of Accounts (account.account) maps to Dynamics G/L Account records. We transfer the account code, account name, and account type (asset, liability, equity, revenue, expense). However, Dynamics requires that G/L Accounts be assigned an Account Category (Income, Expense, Asset, Liability, etc.) that drives the financial statement grouping, which Odoo does not have. We flag accounts without a clear category assignment during scoping and defer those rows until the customer configures Account Categories in Dynamics.

Odoo stock.location records (with location_type: internal, partner, inventory, production) map to Dynamics Locations via the InventLocation and Ward table. We map the Odoo location_complete_name path to the Dynamics Location Name and assign a Location Type. Warehouse-level locations map to Dynamics Warehouse entries used in pick, put-away, and shipping workflows. Sub-location hierarchies in Odoo flatten into separate Location codes in Dynamics because Dynamics does not support recursive location nesting.

Odoo Projects map to Dynamics 365 Finance and Operations Projects (ProjTable / ProjJournalTable) or Business Central Jobs (Job table) depending on the destination product. We transfer the project name, project state (Open, Closed), responsible user mapping from Odoo owner to the Dynamics Worker or Resource, and the project type (Billable, Non-Billable, Internal). Project budgets from Odoo migrate as budget register entries on the destination project if the customer requires budget tracking, though this requires a separate configuration step.

Odoo Tasks map to Job Task Lines within a Job in Business Central or Project Lines in Finance and Operations. We preserve the task name, stage assignment (mapped to a Task Number sequence), responsible Worker from Odoo user assignment, deadline (Due Date), and the parent_id hierarchy as Task Line dependencies. Custom stage names from Odoo Studio become Job Task Line categories pre-configured in Dynamics. Sub-task nesting under a parent task maps to a line number dependency structure in Dynamics.

Odoo Manufacturing Orders (mrp.production) map to Dynamics Production Orders (ProdTable). We transfer the production state (draft, confirmed, in_production, done, cancel), the Bill of Materials reference (resolved from Odoo mrp.bom), the product to manufacture, and the bill of material quantity. Workorder sequences from Odoo map to Production Order Operation Lines with work center assignments. Note that workorder-specific trackings (time tracking, byproduct lines) require re-configuration in Dynamics Operations because Operations routes use a separate capacity planning model that Odoo does not expose via the standard API.

Odoo Bills of Materials (mrp.bom) map to Dynamics Production BOM records (BOMTable / BOMVersion). We preserve the BoM type (kit, manufactured, phantom), component lines with quantities and unit of measure, and the routing reference if the BoM has an associated mrp.routing. Phantom BoMs in Odoo resolve to sub-assembly Items in Dynamics with the phantom explosion handled via the Production BOM structure rather than a separate flag.

Odoo Currency records (res.currency) with active rates map to Dynamics Currencies and Exchange Rate tables. We transfer the currency name, symbol, decimal places, and the current exchange rate as a Currency Exchange Rate entry. Multi-currency configurations in Odoo (where invoices are posted in a foreign currency against a base currency) require explicit configuration of the Dynamics Currency and General Ledger Setup before any posted transactions can be imported, because Dynamics enforces currency rounding at posting.

Odoo Taxes (account.tax) map to Dynamics Tax Groups and Tax Codes. We transfer the tax name, rate (percentage or fixed), scope (sale, purchase), and tax type (account.tax.type: group, percent, fixed). Tax group assignments from Odoo fiscal positions map to Tax Group membership on the destination. However, Dynamics tax calculation uses a posting setup matrix (Tax % Posting Setup) that must be explicitly configured for each Tax Group and Business Posting Group combination, which Odoo does not model the same way.

Odoo Employees (hr.employee) map to Dynamics Human Resources Workers (HcmWorker or Worker in Business Central). We transfer the employee name, work email, department (mapped to a Department lookup in Dynamics HR), job title, and employment status. Employee categories from Odoo map to the Dynamics HR Job function or position. Note that Odoo HR-specific fields (emergency contacts, bank account for payroll, attendance) are Odoo-specific and have no direct Dynamics equivalent without additional HR module configuration.

Odoo uses External IDs (ir.model.data) as the import-reference standard for cross-record lookups during CSV import. Dynamics does not have an External ID field on all entities. We maintain a FlitStack AI migration key mapping table that resolves Odoo External IDs to Dynamics primary keys at migration time, particularly for parent lookups like Partner on Sales Order, Account on Contact, and Item on Sales Line. This mapping table is preserved through all import phases and used for reconciliation.