Migrate from Axelor ERP to Odoo ERP

Axelor Partner is a unified object covering customers, suppliers, and prospects with role classification stored as a field. We split Axelor Partner records into Odoo Contact (the person) and Company (the Account/Company) using the partner's role attribute to determine which records are companies versus individuals. Addresses, bank details, and contact persons stored as related Axelor records migrate to Odoo Contact address fields and bank account records respectively. We normalise the email-to-contact lookup as the dedupe key on import.

Axelor Products (stocked items and services with BOM support) map to Odoo Product Template. Product variants, units of measure, and supplier info stored as related Axelor records migrate to Odoo Product Template variants, uom_id, and seller_ids. Multi-UoM support on Axelor normalises to Odoo's UoM categories and conversion ratios. Product costing method (standard, average, FIFO) migrates as Odoo's cost_method field.

Axelor Sale Orders with line items, taxes, discounts, and status workflows map directly to Odoo sale.order. Order-to-invoice linkage from Axelor's originId migrates as Odoo's origin field linking the sale order to the created account.move. We extract confirmed, partially fulfilled, and cancelled order history and preserve order status as Odoo state values. Customer address and contact person resolve via the Partner-to-Contact/Company lookup.

Axelor Purchase Orders migrate to Odoo purchase.order using the same line-item, tax, and discount mapping as Sale Orders. Vendor address resolves via the Supplier partner classification from Axelor. Open purchase orders at migration time are flagged so that in-flight receipts and moves are reconciled after cutover.

Axelor multi-currency, multi-company-aware invoices map to Odoo account.move records with move_type set to out_invoice or in_invoice. Invoice lines, tax computation, payment terms, and overdue flags migrate as Odoo invoice line entries and account.payment.term references. Open versus historical invoices are separated so that only posted invoices affect Odoo's accounting ledger at migration time.

Axelor Projects with Tasks, Milestones, Time Entries, and Invoicing Plans map to Odoo project.project. The full project hierarchy including subtask nesting, assigned users, and billing rates migrate as Odoo project task records and analytic account entries. Project status and any Axelor custom fields on the project record map to Odoo project custom fields. Billing rates migrate to project pricing rules on the Odoo project.

Axelor Tasks belonging to Projects with status, priority, assignees, and custom fields map to Odoo project.task. Subtask inheritance that varies by Axelor version is flattened where Odoo does not support nested tasks natively. Task assignments resolve via the Owner-to-User email lookup. Time entries stored against Axelor Tasks migrate as Odoo account.analytic.line linked to the project.

Axelor Stock Moves tracking internal transfers, receipts, and shipments with real-time inventory impact map to Odoo stock.move and stock.quant. Move lines, warehouse assignments, and lot/serial numbers migrate as Odoo stock.move.line and stock.lot records. Open moves at migration time are flagged so that the customer reconciles any in-flight transfers after cutover. Current stock levels migrate as Odoo stock.quant records for inventory valuation accuracy on day one.

The Axelor Chart of Accounts, Journals, and Journal Entries with debit/credit lines and analytic accounts map to Odoo's account.account, account.journal, and account.move tables. This is the highest-risk object in the migration because chart-of-accounts structure varies significantly between deployments. We review the source database schema during scoping to identify the exact journal and account configuration before designing the Odoo account.account entries. Historical journal entries migrate as Odoo account.move records in draft state for customer review before posting.

Axelor Employee records with contact info, job title, department, and employment dates map to Odoo hr.employee. Reporting-line structure migrates as the parent_id and coach_id relationships in Odoo hr.employee. Employment dates and department assignments are preserved for HR reporting continuity. Any Axelor custom fields on the employee record are noted for manual field creation in Odoo before employee data import.

Axelor BOMs defining product component lists and routing steps for manufacturing map to Odoo mrp.bom records. BOM versioning in Axelor is preserved by mapping the active BOM to the Odoo mrp.bom with the latest effective date; alternate BOMs are carried as mrp.bom records with alternative flag. Routing steps map to Odoo mrp.workcenter records linked to the BOM. This mapping is only in scope when the Odoo Manufacturing module is activated on the destination instance.

Axelor Studio custom domain objects require explicit enumeration during scoping. We request access to the application's XML domain files or a full database schema dump to identify every non-standard model. Each custom Studio object is then mapped to an Odoo custom model with __c suffix and equivalent field types. Custom Studio fields that reference standard Axelor objects (Partner, Product, Order) are created as Odoo many2one or many2many fields pointing to the corresponding standard Odoo model. BPM workflows built in Axelor Studio do not migrate as code.