Migrate your Axelor CRM data

Leads are first-class CRM objects in Axelor that can be tracked through the pipeline, closed, or converted to Third Parties (customers/prospects). We map Leads 1:1 and preserve the conversion history when migrating to another CRM by recording the conversion timestamp and associated Opportunity link.

Third Parties represent the core Contact/Company entity in Axelor CRM. They support type-based classification (customer vs prospect), notes, and agency associations. We map Third Parties to the destination's Contact or Company object and preserve the type as a custom field.

Contacts in Axelor are distinct from Third Parties and are linked to a parent Third Party record. We maintain the parent-child relationship during migration by matching or creating the parent Third Party first, then linking Contacts.

Opportunities track potential sales with stages, expected amounts, and optional recurrent revenue fields. We preserve stage sequences, revenue amounts, and any configured recurring period fields. Opportunity-to-Lead and Opportunity-to-Contact associations are maintained through external ID mapping.

Axelor supports PDF catalogue storage linked to Third Parties for sales staff reference. We extract catalogue metadata and links, but the actual binary files require separate file-transfer handling outside the standard data export. We flag catalogue attachments for manual transfer or configured blob storage migration.

Agencies are a distinct routing and segmentation concept in Axelor CRM that associates Leads and Third Parties. Most destination CRMs do not have a native Agency object, so we create Agencies as Tags or custom lookup fields and apply them to the associated records during import.

The lead-to-agency assignment is a many-to-many relationship. We resolve this by creating a junction export that maps each Lead ID to its associated Agency IDs, then reconstruct the associations in the destination using Tags or a custom junction object.

The 'Manage recurrent revenue on opportunities' setting adds expected recurring amount and period fields to Opportunities. These are custom fields added via configuration. We detect their presence during schema inspection and include them in the field mapping scope.

Axelor Studio allows creating entirely new objects beyond the standard CRM entities. These are defined in XML and generated as JPA models. We inspect the XML schema for custom objects during scoping and handle them as Custom Objects in the destination with field-level mapping.

Axelor's BPM engine defines workflow logic and business rules. These are not exported as data records—they are embedded application configuration tied to the Studio and J2EE deployment. We do not migrate BPM workflows. Customers must rebuild automation logic in the destination system.

Axelor user records include roles, organizational structure, and access permissions. We extract user identity data for mapping record ownership in the destination, but role and permission schemas are platform-specific and require manual reconfiguration.

Axelor DMS stores documents linked to CRM records. Binary attachments are exported separately from the data record export. We include document metadata in the migration scope and provide guidance on DMS file transfer as a parallel step to the record migration.