Migrate from Axelor CRM to Microsoft Dynamics 365 Sales

Axelor Leads map directly to Dynamics 365 Sales Lead. We extract the Lead XML record, map standard fields (full name, email, phone, company, status, rating, source) to Lead entity columns, and preserve the original Axelor lead ID in a custom field axelor_lead_id__c for reconciliation. Lead conversion history (when the Lead was converted to a Third Party in Axelor) migrates as a text note because Dynamics 365 Lead does not natively record conversion audit trails between unrelated systems.

Axelor Third Party is a combined Contact-and-Company entity with type classification (customer vs prospect), address, industry, and notes. We split each Third Party into a Dynamics 365 Account record (the company data) and a Contact record (the primary contact). Contact.FirstName is derived from the Axelor name field; Contact.ParentId links to the Account. Axelor Third Party type = 'Prospect' maps to Account.AccountType = 'Prospect Customer'; type = 'Customer' maps to Account.AccountType = 'Customer'.

Axelor Contacts are child records linked to a parent Third Party. We resolve the parent Third Party's split target Account during import, then insert each Contact with the resolved AccountId. Axelor contact roles (buyer, influencer, approver) have no direct Dynamics 365 equivalent; we store role information in Contact.Description or a custom contact_role__c field per customer preference. If the parent Third Party was not migrated (filtered out or deleted), the Contact is linked to the Account nearest by name match.

Axelor Opportunities map to Dynamics 365 Sales Opportunity with AccountId resolved from the linked Third Party. The Axelor pipeline stage (Lead → Qualified → Proposal → Won/Lost) maps to a configured Dynamics 365 Sales Process with matching stage values. ExpectedCloseDate, EstimatedRevenue, and Probability migrate directly. Recurring revenue fields (active only when 'Manage recurrent revenue on opportunities' is enabled in Axelor CRM settings) migrate to custom decimal fields recurring_amount__c and recurring_period__c in Dynamics 365.

Axelor's agency-based lead routing is a many-to-many relationship between Leads and Agencies. Dynamics 365 Sales has no native Agency object, so we export the Lead-to-Agency junction table, extract unique agency names, and create Dynamics 365 Tags from them. Each Lead receives Tag assignments matching its agency associations. We document the full junction mapping in a CSV delivered alongside the migration so that the customer's admin can build Power Automate flows or assignment rules from the agency associations if needed.

Axelor catalogue metadata (product catalogue name, linked PDF reference, description) migrates as a Note record or SharePoint Document Location linked to the parent Third Party Account. The actual PDF binary files are exported separately as a file package; we provide a file-transfer guide and folder mapping for manual SharePoint upload or blob storage transfer into Dynamics 365's connected SharePoint environment.

Axelor Studio custom objects that represent product catalogue entries (distinct from the standard Catalogue metadata) map to Dynamics 365 Product2 records. We inspect the XML model definition during scoping to identify the field structure, map field names to Product2 standard columns (Name, ProductNumber, Description, Price), and create any custom fields with appropriate Dataverse column types before product import.

Axelor Studio allows entirely new objects beyond standard CRM entities, defined as XML and compiled to JPA models. We inspect the XML schema during scoping, infer field names and data types, and pre-create corresponding Dataverse custom tables in the Dynamics 365 environment before any data import. Lookup relationships between custom objects are resolved during import by matching foreign-key values to the target table records already inserted earlier in the sequence. Standard Axelor Studio types (string, integer, decimal, date, boolean, many-to-one, many-to-many) map to Dataverse column types with appropriate validation rules.

Axelor user records contain identity data, role assignments, and organizational structure. We extract user display name and email address, match by email against the Dynamics 365 destination User table, and map the OwnerId on migrated records to the resolved User. Users without a Dynamics 365 User account enter a reconciliation queue; the customer's admin provisions the missing accounts before migration resumes. Role and permission schemas do not migrate because they are application configuration, not data.

Axelor DMS stores binary documents linked to CRM records. Document metadata (filename, linked entity type, linked entity ID, upload date) exports from the AppLoader XML. We map document links to SharePoint Document Location records pointing at a pre-created SharePoint folder structure mirroring the Axelor entity hierarchy. The binary files are provided as a separate file package for the customer to upload into the SharePoint environment. Note records serve as a fallback for document metadata if SharePoint integration is not configured at migration time.

Axelor tasks linked to Third Parties, Leads, or Opportunities map to Dynamics 365 Task records. The WhoId on Task resolves to the migrated Contact or Lead ID; the WhatId resolves to the migrated Account or Opportunity ID. Task.Subject, Description, Priority, and ActivityDateTime migrate directly. Task status (Open/Completed) maps from Axelor's task status field.

Axelor notes attached to any CRM entity map to Dynamics 365 Annotation records with IsDocument = false. The parent ObjectId links to the migrated record ID in the target entity table (Account, Contact, Lead, or Opportunity). Note body migrates as plain text; any embedded file references are exported as separate document packages.