Migrate from Axelor CRM to Odoo CRM

Axelor Lead records map directly to Odoo crm.lead. The Lead name, email, phone, source, medium, and expected closing date migrate to Odoo Lead fields. The Axelor lead agency assignments (many-to-many junction) are resolved by creating Odoo tag records for each Axelor Agency and applying them to the corresponding migrated Lead records. Lead priority and rating from Axelor map to Odoo's priority field and a custom stage-based rating field.

Axelor Third Party is the core Contact/Company entity that covers both customers and prospects. We split the Axelor isCustomer flag: Third Parties where isCustomer is true map to Odoo Partner with customer_rank set to create a Customer Partner; those where isCustomer is false map to a Vendor Partner or remain as Prospect-ranked. The Axelor Third Party type (customer, prospect, vendor, both) drives the Odoo Partner category and is_customer, is_company boolean flags. Parent-child Third Party hierarchies (holding-subsidiary relationships) map to Odoo Partner's parent_id relationship.

Axelor Contacts are distinct child records linked to a parent Third Party. During migration, we create Odoo Partner records with is_company=False for each Axelor Contact and set the parent_id to the Partner created from the Contact's parent Third Party. The Axelor Contact's role, function, and direct phone/email fields map to the Odoo Partner function field and contact fields. If the parent Third Party does not yet exist at Contact migration time, we create it first.

Axelor Opportunities map to Odoo Opportunities (crm.lead with type='opportunity'). The Axelor stage name, expected amount, and probability migrate to Odoo's stage_id and expected_revenue fields. The partner_id on Odoo Opportunity resolves to the Partner created from the linked Third Party. If the Axelor Opportunity references a Contact (salePartner), that Contact's parent Third Party becomes the Odoo partner_id.

Axelor Opportunity stage names and their sequence order map to Odoo CRM Stage records within the customer's Pipeline. We create stages in the same sequence order and assign probabilities matching the Axelor stage configuration. If the Axelor deployment uses custom stage names (beyond the default New, Qualified, Proposal, Won, Lost), we preserve them in Odoo stage names to avoid data misinterpretation.

The recurrent revenue amount and default recurring period fields on Axelor Opportunities exist only when 'Manage recurrent revenue on opportunities' is activated in Axelor CRM settings. We detect these fields during scoping by inspecting the Opportunity XML schema. When present, we create matching custom fields on the Odoo crm.lead model (recurrent_amount, recurrent_period) before Opportunity data import. The customer configures these fields in Odoo Studio post-migration.

Agencies are a distinct Axelor CRM concept for routing and segmenting leads and Third Parties. Odoo has no native Agency object. We extract the Agency records as a distinct dataset, create Odoo crm.tag records for each Agency, and apply them to the migrated Leads and Partners. The many-to-many junction between Lead and Agency is resolved as a multi-tag assignment on each Lead during migration. Customers requiring agency-based routing in Odoo beyond tagging can configure this via Odoo Sales Team assignment rules.

Axelor Studio custom objects are defined in XML and compiled to JPA models at deployment. We inspect the XML schema for each custom object during scoping, infer field names and data types, and create corresponding Odoo custom models via the Studio interface or a technical module. Custom fields on standard objects map to Odoo custom fields with equivalent types (char, integer, float, date, many2one, selection). Objects defined in XML as enums map to Odoo selection fields. This work is scoped as technical configuration during migration; the customer provides the XML model definitions during discovery.

Axelor user records include roles, organizational structure, and access permissions used for record ownership assignment. We extract the user identity data (name, email, active status) and match by email against the destination Odoo User table. Owners without a matching Odoo User are held in a reconciliation queue; the customer's Odoo admin provisions missing users before record import resumes. Role and permission schema do not migrate; Odoo's access rights model is fundamentally different from Axelor's role-based configuration.

Axelor DMS stores binary documents linked to CRM records. We export document metadata (filename, URL, file size, record reference) and include it in the migration scope as an attachment manifest. The actual binary files require a separate file transfer step using SFTP or cloud storage, outside the API-based migration scope. We provide the attachment manifest mapping each Axelor document to its target Odoo record (res_model, res_id) so the customer's admin can finalize the file transfer post-migration.

Axelor notes linked to Leads, Third Parties, or Opportunities migrate to Odoo mail.message records with message_type='comment' on the corresponding Odoo record. The note body, author, and creation timestamp preserve. Notes with attachments resolve the attachment references against the attachment manifest to link files to the Odoo record.

Axelor task and meeting engagements linked to CRM records migrate to Odoo project.task records for tasks (with project_id=None for CRM-only tasks) and calendar.event records for meetings. The assignee maps from Axelor owner to Odoo User via the owner reconciliation queue. Meeting location and attendee information migrates to Odoo calendar.event and calendar.attendee records. Historical task and meeting data is migrated after Leads, Third Parties, and Opportunities are in place so that the parent record references resolve.