Migrate from Axelor ERP to Dolibarr ERP

Axelor Partner is a unified object for customers, suppliers, and prospects with addresses, bank details, and contact persons stored as related records. It maps to Dolibarr's ThirdParty (societe) table. We split the Axelor Partner type (customer, supplier, prospect) into Dolibarr's separate isCustomer and isSupplier boolean flags on the same record. Contact persons map to Dolibarr's contact table with the parent third-party reference preserved as s.fk_soc.

Axelor Products cover both stocked items and services with BOM support for manufacturing, product variants, units of measure, and supplier info. They map to Dolibarr's Product table with type (0=service, 1=stockable, etc.), barcode, and price information. Multi-UoM is normalised to Dolibarr's single unit of measure per product with weight and volume dimensions migrated as product attributes.

Axelor Sale Orders carry line items, taxes, discounts, and status workflows with order-to-invoice linking preserved via originId. They map to Dolibarr's commande table with order status (0=draft, 1=validated, etc.), and order lines migrate to commande_fournisseurdet for supplier orders or commande_det for customer orders. The Axelor currency code maps to Dolibarr's fk_multicurrency field for multi-currency orders.

Axelor Purchase Orders map to Dolibarr's commande_fournisseur table with supplier reference, order status, and line items. Axelor's purchase order workflow states map to Dolibarr's Status values. We resolve the supplier third-party reference to Dolibarr's fk_soc during import and preserve the purchase representative as aDolibarr user assignment.

Axelor Invoices are multi-currency and multi-company aware with invoice lines, tax computation, payment terms, and overdue flags. They map to Dolibarr's facture table, with type区分 customer invoice (facture), supplier invoice (facture_fournisseur), and credit note (factureavoir). Open invoices vs historical records are separated so that only posted invoices are imported. Axelor's originId linking to orders is preserved as fk_origin on the Dolibarr record.

Axelor Projects contain Tasks, Milestones, Time Entries, and Invoicing plans in a hierarchical structure. They map to Dolibarr's projet table. The full project hierarchy including subtask nesting and assigned users migrates, with project status mapped from Axelor's state to Dolibarr's fk_statut. Dolibarr does not support native project hierarchies beyond one level, so we flatten multi-level Axelor project trees into a flat project list with a parent_reference custom field for the customer to re-establish relationships manually.

Axelor Tasks belong to Projects and carry status, priority, assignees, and custom fields. They map to Dolibarr's projet_task table with the parent project reference preserved as fk_projet. Axelor's task date fields map to dateo (start) and datee (end), and the Axelor assigned user maps to fk_user_assign. Subtask inheritance varies by Axelor version; we flatten nested task hierarchies to flat tasks with a parent_task reference for Dolibarr's admin to reassemble if needed.

Axelor Stock Moves track internal transfers, receipts, and shipments with real-time inventory impact. They map to Dolibarr's stock_mouvement table with warehouse references (Axelor fromWarehouse/toWarehouse to Dolibarr fk_entrepot), lot/serial numbers ( Axelor lotNumber to Dolibarr lot_id), and move quantities. Open moves at migration time are flagged so that partial stock impact is reconciled against Dolibarr's current stock levels after import.

Axelor ProductStock represents real-time inventory quantities per product per warehouse. It maps to Dolibarr's product_stock table (or stock_reel computed from stock_mouvement) with product reference, warehouse reference, and physical quantity. We take a snapshot of current stock levels at migration time and use them to seed Dolibarr's stock warehouse records, reconciling against any open stock moves imported separately.

Axelor's General Ledger with Chart of Accounts, Journals, and Journal Entries maps to Dolibarr's accounting tables (accounting_account for the chart of accounts, accounting_document for journal entries, and accounting_lines for debit/credit lines). Multi-company journal entries with debit entries in one company and corresponding credit entries in another are split into separate standard journal entries per company, and the inter-company relationship is flagged via a custom reference field (intercompany_ref) for manual reconciliation post-migration. We do not replicate Axelor's analytic accounting structure unless the destination Dolibarr installation includes the accountancy module.

Axelor Employee records include contact info, job title, department, and employment dates. They map to Dolibarr's user table with the employee's login, last name, first name, email, and job title migrated. The Axelor department maps to Dolibarr's departmental custom field. User-to-record ownership mappings are preserved by resolving the employee reference to Dolibarr's fk_user on related records.

Axelor Studio allows creation of entirely custom domain objects defined in XML files and compiled into the application at build time. We enumerate every custom model by inspecting the application's XML domain files during scoping. Each custom object is mapped to a Dolibarr custom object or a new Dolibarr module depending on complexity. Custom fields stored in Axelor's attrs JSON column are enumerated and mapped to Dolibarr's extrafields table structure. If a custom object has relationships to standard Axelor objects, we replicate those relationships in Dolibarr via foreign key fields. Custom objects without a clear Dolibarr equivalent are documented in the migration handoff with a recommended module approach.

Axelor BPM processes and decision tables are stored as application-level configuration exported as DMN XML or Excel files rather than database records. They do not migrate as executable code into Dolibarr. We extract the relevant XML files from the Axelor application deployment and produce a written inventory of every BPM process with its trigger conditions, steps, decision logic, and referenced object types mapped to Dolibarr equivalents. The customer admin or a Dolibarr implementation partner uses this inventory to rebuild the processes in Dolibarr's workflow system or via a third-party workflow add-on.

Axelor stores file attachments in a designated filesystem directory or database blobs depending on configuration. The REST API returns attachment metadata but does not stream file binary content in bulk. We export attachment metadata (filename, size, record association, creation date) during migration scoping and schedule a separate SFTP or cloud storage sync job to transfer actual file binaries to Dolibarr's document directory. The record associations are written to Dolibarr's ecm_files table and linked to the migrated record via entity/type/id columns.

Axelor user records carry email, role, and team membership. Role-to-permission mappings vary significantly between Axelor versions. We extract user identity (email, name, active status) and role names but recommend manual permission review in Dolibarr after migration because Dolibarr's permission model (right_def based) differs structurally from Axelor's role definitions. Active Axelor users are provisioned as Dolibarr users; inactive users are imported with status=0 and flagged for the customer admin to activate if needed.