Migrate from Axelor CRM to Twenty CRM

Axelor Leads migrate to Twenty Person records as first-class CRM objects. The Axelor lead status (New, Assigned, Qualified, Lost, Converted) maps to a Twenty select field representing the original status, and the conversion timestamp from Axelor becomes a date field on the Twenty Person record. Any agency routing assignments on the Lead are resolved via the lead-agency junction table and reconstructed as Tags on the Person after the Tag object is pre-created in Twenty.

Axelor Third Parties represent both organizations and individuals within those organizations, a single object handling both roles. We perform a split at migration time based on the Third Party type field: type=Customer or type=Prospect with no individual name fields maps to Twenty Company; type=Customer or type=Prospect with an individual name maps to Twenty Person and optionally also creates a linked Company. The original Third Party type is preserved as a custom field for reporting continuity. The parent-child Contact relationship from Axelor is resolved against the split output.

Axelor Contacts are child records linked to a parent Third Party. After the Third Party split into Person and Company objects, we match each Contact to its parent by resolving the Third Party ID to the corresponding Twenty Person or Company record. The Contact's name, email, phone, and role fields migrate to the corresponding fields on the Twenty Person record, and the original Third Party ID is preserved in a custom field for audit traceability. Contacts without a resolvable parent Third Party are held in a reconciliation queue.

Axelor Opportunities map directly to Twenty Opportunities. The pipeline stage name from Axelor becomes a select field value on the Twenty Opportunity, and the expected revenue amount migrates to the standard amount field. If the recurrent revenue configuration is active on the source (detected during scoping XML inspection), the recurring amount and period fields migrate as custom fields on the Opportunity in Twenty. The opportunity linked Third Party ID is resolved against the post-split Person or Company record.

Axelor Agencies are a distinct routing and segmentation concept with no native equivalent in Twenty CRM. We pre-create a Tag object in Twenty during the schema design phase and map each Axelor Agency to a Tag with the agency name. The Tagging functionality in Twenty must be enabled in the workspace settings before migration, as Tags are not created by default. Customer admin confirms the tagging strategy during scoping.

The lead-to-agency assignment in Axelor is a many-to-many relationship stored in a junction table. We export this as a standalone lookup file during the Axelor AppLoader data extraction, then reconstruct the associations in Twenty by creating Tag records for each distinct Agency and applying them to the corresponding Person records. The junction table export is performed before the main record migration so that Tags are available for assignment during the Person load.

Axelor Studio custom objects are defined in XML and compiled to JPA models, with no standard export format beyond the AppLoader package. We perform a schema inspection step that reads the XML model definitions from the Axelor application configuration, infers the field structure (names, data types, required flags), and generates a Twenty custom object schema before any data extraction begins. All custom fields are created in Twenty via the UI or API before the custom object data migration starts, including any lookup relationships to standard objects that must exist first.

The recurrent revenue amount and default recurring period fields on Axelor Opportunities appear only when the 'Manage recurrent revenue on opportunities' checkbox is activated in the CRM settings. We detect this configuration during scoping by inspecting the Opportunity XML schema for the recurring revenue fields and include them in the migration scope only when present. In Twenty, we create custom number and select fields on the Opportunity object before migration and map the values directly.

Axelor DMS stores documents linked to CRM records as binary files. We extract document metadata (filename, linked object type, linked record ID, creation date, author) from the AppLoader export and include it in the migration scope. The binary files themselves require separate file-transfer handling outside the standard data migration and are flagged for the customer's IT team to relocate to a shared file store or Twenty's document attachment storage post-migration.

Axelor user records include roles, organizational structure, and access permissions that do not export as data. We extract user identity data (user ID, email, full name, active/inactive status) from the Axelor AppLoader export for mapping record ownership in Twenty. We match by email against the Twenty User table. Any Axelor user without a matching Twenty User goes to a reconciliation queue for the customer's admin to provision before record import proceeds. Role and permission schemas are not migrated.