Migrate from Axelor ERP to Microsoft Dynamics 365 Business Central

Axelor Partner is a unified object covering customers, suppliers, and prospects with name, address, bank details, and multiple contact persons stored as related sub-records. We split this into Microsoft Dynamics 365 Account (the organisation or company) and Contact (the individual contact person). The Partner type field (customer, supplier, prospect) maps to the Account's classification or a custom field. Each Axelor Partner contact sub-record becomes a separate Dynamics Contact linked via the AccountId lookup. Multi-address support (billing and delivery) maps to the Dynamics address purpose model.

Axelor Products cover stocked items and services with BOM support, variants, units of measure, and supplier information stored as related records. We map them to Dynamics 365 Released Products (F&O) or Item records (Business Central). Product variants in Axelor map to Dynamics product dimensions (size, color, style). BOMs map to Bills of Materials in Dynamics 365 Manufacturing (F&O) or Business Central's production BOM. Multi-UoM in Axelor maps to the Dynamics unit of measure conversion framework.

Axelor Sale Orders carry line items, taxes, discounts, and status workflows with order-to-invoice linking preserved via the originId field. We extract confirmed, partially fulfilled, and cancelled orders separately. Status workflows in Axelor map to the Dynamics Sales Order status workflow. Header-level charges and discounts in Axelor require mapping to Dynamics Sales Header Charges or a custom field. Lines link to the Released Product or Item.

Axelor Purchase Orders mirror the Sale Order structure but in the procurement direction. We preserve order history including confirmed, partially received, and closed orders. Purchase Order status workflows map to the Dynamics approval workflow model. Line items link to the Axelor Product mapping established during the product import phase.

Axelor invoices are multi-currency and multi-company aware with invoice lines, tax computation, payment terms, and overdue flags. Open invoices migrate before cutover; historical paid invoices migrate as read-only or archived records depending on the customer's reporting needs. Multi-currency in Axelor maps to the Dynamics currency exchange rate framework. Payment terms map to Payment Terms and Schedules in Dynamics.

Axelor Projects contain Tasks, Milestones, Time Entries, and Invoicing plans in a full project hierarchy. We extract subtask nesting and assigned users and flatten the hierarchy where the destination does not support nested task structures. Project status and custom fields map to the corresponding project stage and custom fields in Dynamics. Time Entries migrate as Project Time Transactions or Time Sheet Lines depending on the destination product.

Axelor Tasks belong to Projects with status, priority, assignees, and custom fields. Subtask inheritance varies by Axelor version; we flatten nested task hierarchies where the Dynamics destination does not support nested task structures, preserving the parent-child relationship in a custom field for reporting. Task status workflows map to the Dynamics project task status model.

Axelor Stock Moves track internal transfers, receipts, and shipments with real-time inventory impact, lot and serial numbers, and warehouse assignments. We extract move lines, warehouses, and lot/serial numbers. Open moves at migration time are flagged and must be completed or cancelled in Axelor before cutover. Lot and serial number records migrate as inventory tracking data in Dynamics. Current stock on hand migrates as inventory closing entries.

The Axelor Chart of Accounts, Journals, and Journal Entries form the accounting core with debit/credit lines and analytic accounts stored per entry. Multi-company journals require inter-company reconciliation because Dynamics 365 Finance does not natively replicate the inter-company journal entry model. We split inter-company debit/credit pairs into separate per-company journal entries and add a custom reference field linking the counterpart entries for manual reconciliation post-migration. Historical balances migrate as opening transactions.

Axelor Employee records include contact info, job title, department, and employment dates. We map to the Worker entity (F&O, Human Resources module) or Employee entity (Business Central). Reporting-line structures and department assignments map to the corresponding Dynamics HR hierarchy. Employment dates and status preserve for payroll continuity.

Axelor stores file attachments in a designated application filesystem directory or database blobs depending on the deployment configuration. The REST API returns attachment metadata (filename, size, record association) but does not stream file binary content in bulk. We export attachment metadata and schedule a separate SFTP or cloud storage sync job to move the actual document binaries to the Dynamics-connected SharePoint Online environment or Azure Blob storage, then create SharePoint file references or Dataverse Note records linked to the migrated parent records.

Axelor Studio allows entirely custom domain objects stored in the same database with XML model files. Each non-standard model must be enumerated at scoping time by inspecting the application's XML domain files or requesting a full DB schema dump. We extract the custom object's records, pre-create the equivalent custom entity in Dynamics 365 (Power Apps maker portal), define all custom fields with matching data types, then import the records in dependency order if the custom object has lookups to standard Axelor objects. Custom objects with cross-references to other custom objects are imported in topological order to satisfy foreign key constraints.

Axelor BOMs define product component lists and routing steps for manufacturing with versioning. We map the active BOM to the destination product and carry alternate BOM references as inactive versions. BOM routing steps map to Operations (F&O) or Work Centre and Machine Centre (Business Central). BOM version validity dates migrate as version effective date ranges in Dynamics.

Axelor user records carry email, role, and team membership with role-to-permission mappings that vary significantly between versions. We extract user identity and role names and map them to the Dynamics 365 User table by email match. Any user without a matching Dynamics User is held in a reconciliation queue for the customer's admin to provision before record import resumes. Role-to-permission mappings are documented as a written handoff; we recommend a manual permission audit post-migration rather than automated role translation because permission models differ substantially.