Migrate from Axelor CRM to Salesforce Sales Cloud

Axelor Lead records map 1:1 to Salesforce Lead. The Axelor lead status field maps to Salesforce Lead Status, and any lead source field maps to LeadSource. We preserve the conversion history (whether the Lead was converted to a Third Party in Axelor) in a custom field axelor_conversion_status__c. If the Lead was already converted to a Third Party, we also create the corresponding Salesforce Account and Contact and link them via the Lead Convert action, with the Lead retained as a historical record.

Axelor Third Party records are the core company and person entity and must be split: company data (name, address, industry, revenue) maps to Salesforce Account, and person data (individual name, email, phone if stored on the Third Party) is extracted as a separate Contact. We detect the type field (customer vs prospect) and map it to Account Type. Agency associations on Third Parties are stored in a junction table that we resolve after Account creation (see Lead Agencies mapping).

Axelor Contact records are distinct from Third Parties and are linked to a parent Third Party record. We maintain the parent-child relationship by resolving the parent Third Party ID to the newly created Salesforce Account ID at migration time. Email, phone, title, and department fields map directly. Any Contact without a resolvable parent Third Party is held in a reconciliation queue and mapped to a Prospect Account (an Account record with Name = 'Prospect' created during initial setup).

Axelor Opportunity records map 1:1 to Salesforce Opportunity. StageName maps from Axelor opportunity status, Amount maps from the expected revenue field, CloseDate maps from the expected closing date, and Description maps from the opportunity notes field. The linked Third Party (customer or prospect) is resolved to the Salesforce Account ID. If the Axelor Opportunity has a primary Contact, we resolve that Contact and populate OpportunityContactRole. The Opportunity Owner maps from the Axelor user record.

Axelor adds expected recurring amount and recurring period fields to Opportunities only when the 'Manage recurrent revenue on opportunities' setting is activated. We detect this configuration during scoping by inspecting the Opportunity XML schema for the recurring revenue fields. If present, we create Salesforce custom fields Recurring_Amount__c (Currency) and Recurring_Period__c (Text) on Opportunity and populate them from the Axelor values. If the setting is not active, no equivalent fields exist and nothing is created.

Agencies in Axelor CRM are a distinct routing and segmentation concept that associates Leads and Third Parties. Salesforce has no native Agency object. We create Salesforce Tags (with Tag Name = Agency name) during migration and link them to the relevant Account and Lead records via TopicAssignment. The customer chooses whether to use Salesforce standard Tags or a custom multi-select picklist on Account during scoping.

The Axelor lead-to-agency assignment is a many-to-many relationship stored in a junction export. We export the Lead ID to Agency ID pairs, then create TopicAssignment records linking each Lead to the Tag representing its Agency. The same junction resolution applies to Third Party-to-Agency relationships, creating TopicAssignment records on Account. This preserves the agency routing and segmentation logic in Salesforce without requiring a custom junction object.

Axelor supports PDF catalogue storage linked to Third Parties for sales staff reference. We extract catalogue metadata (filename, linked Third Party ID, creation date) and preserve it as a record in a custom Catalogue__c object with a URL field pointing to the source location. The actual binary files require separate file-transfer handling outside the migration scope; we provide guidance on DMS migration and do not attempt to move binary blobs through the Salesforce REST API.

Axelor Studio allows creating entirely new objects beyond the standard CRM entities, defined in XML and compiled to JPA models. We inspect the XML schema for each custom object during scoping, infer field names and data types, and create equivalent Salesforce custom objects with __c API names before migration. Any lookup fields in the Axelor custom object that reference standard entities (Third Party, Contact, Opportunity) are resolved to Salesforce IDs during staging. Custom Studio objects without a clear Salesforce equivalent are documented with the full schema and a recommendation (custom object, junction object, or multi-select picklist on an existing object).

Axelor user records include name, email, organizational structure, and access roles. We extract user identity data for mapping record ownership in Salesforce. Role and permission schemas are not migrated because they are application configuration with no data-record equivalent. We match Axelor users by email against the Salesforce destination org's User table. Users without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before record import resumes.

Axelor DMS stores documents linked to CRM records. Binary attachments are exported separately from the data record export. We include document metadata (filename, linked entity, creation date, document type) in the migration scope as records in a custom Document__c object. For binary files, we provide guidance on DMS migration using Salesforce Content API but do not migrate file blobs inside the standard migration scope; large document migrations are scoped separately.

Axelor BPM workflows are stored as DMN XML application configuration tied to the J2EE deployment, not as data records. The AppLoader can package DMN models for deployment to another Axelor instance, but this is an application deployment action, not a data export. We do not migrate BPM workflows. We document every identified workflow trigger, condition, and action as a written specification with a recommended Salesforce Flow equivalent for the customer's admin to rebuild post-migration.