Migrate from Axelor CRM to HighLevel

Axelor Lead records map directly to GoHighLevel Contacts representing prospects. The Axelor leadStatus and leadSource fields map to GoHighLevel custom fields on Contact. We preserve the Lead's conversion history (if previously converted to Third Party) as a custom text field since GoHighLevel does not track conversion events the same way. Agency assignments on Leads are resolved through the Lead-Agency junction export and applied as GoHighLevel tags during the same migration phase.

Axelor Third Parties (customers and prospects) map to GoHighLevel Contacts. The Third Party type field (customer vs prospect) maps to a GoHighLevel custom picklist field. The agency's association with the Third Party migrates as a tag on the Contact. Notes and address data transfer to GoHighLevel Contact fields directly. Parent-child Contact relationships (Contacts linked to a parent Third Party) map as GoHighLevel Contacts with a custom lookup field referencing the parent Contact.

Axelor Contacts are distinct records linked to a parent Third Party. We resolve the parent Third Party reference at migration time and map the Contact to a GoHighLevel Contact record with a custom field linking to the parent Contact record. Email, phone, and role fields transfer to the corresponding GoHighLevel Contact fields. If the parent Third Party does not yet exist in GoHighLevel, we create it first before inserting the child Contact.

Axelor Opportunities map to GoHighLevel Pipeline Deals. The opportunity stage maps to a GoHighLevel Pipeline stage. The expectedAmount field maps to the Deal value. The closeDate maps to the GoHighLevel Deal close date. We configure the GoHighLevel Pipeline (or create one matching the Axelor pipeline structure) before migration so that stage values are valid on insert. The salesRep owner maps to a GoHighLevel Team Member.

Each Axelor Opportunity stage becomes a GoHighLevel Pipeline stage. Stage probability values from Axelor migrate as Custom Fields on the Pipeline Deal since GoHighLevel stages do not natively carry probability percentages. Stage names and order are preserved. If the customer uses multiple Axelor pipelines, we create multiple GoHighLevel Pipelines or use GoHighLevel Pipeline Tags to segment.

Axelor Agency records have no native GoHighLevel equivalent. We create GoHighLevel Tags named after each Agency (Agency Name as the tag label). The Lead-Agency junction table is exported separately as a mapping list. During Contact insert, we apply the corresponding tag(s) to each Contact based on the junction. This reconstructs the agency-routing segmentation in GoHighLevel's tag-based model.

The Axelor many-to-many Lead-Agency relationship is resolved by exporting a junction table mapping each Lead ID to its associated Agency IDs. We cross-reference the Lead IDs against migrated Contact records and apply the corresponding GoHighLevel tags. This step runs concurrently with Contact migration to avoid a separate reconciliation pass.

Axelor's 'Manage recurrent revenue on opportunities' setting adds recurringAmount and recurringPeriod fields to Opportunities only when that configuration flag is active. We detect the presence of these fields during scoping by inspecting the Opportunity XML schema. When present, we create GoHighLevel Custom Fields (e.g., Recurring Amount, Recurring Period) on the Pipeline Deal object and migrate the values as custom field data.

Axelor Studio custom objects are defined in XML and compiled to JPA models at deployment. We inspect the XML schema definitions during scoping to infer field names, data types, and relationships. We then pre-create equivalent GoHighLevel Custom Objects with matching field definitions before data extraction. Lookup relationships between custom objects and standard objects (Lead, Third Party, Opportunity) are resolved using the same parent-record lookup strategy used for standard objects. This step requires the most scoping time of any object in the migration.

Axelor Catalogue records store PDF files linked to Third Parties for sales staff reference. We extract catalogue metadata (name, description, linked Third Party reference) and store it as GoHighLevel Custom Fields on the Contact or as an attachment note. The actual binary PDF files require a separate file-transfer step outside the API migration scope; we coordinate with the customer on file hosting (S3, Dropbox, or GoHighLevel's native file storage) and provide a mapping guide linking files to the correct Contact record.

Axelor DMS documents linked to CRM records are exported separately from the data record export. We extract document metadata (filename, type, linked record reference) and map document links to GoHighLevel Notes attached to the corresponding Contact or Pipeline Deal. Binary file transfer for attachments requires a separate file-transfer step coordinated with the customer, similar to the catalogue handling. We do not migrate document binary content via the GoHighLevel API; we provide a file inventory and linking guide.

Axelor User records include identity data for mapping record ownership. We extract the Axelor user list (name, email, role) and match by email against GoHighLevel Team Members. Any Axelor owner without a matching GoHighLevel user goes to a reconciliation queue for the customer to provision the GoHighLevel user before record migration resumes. Role and permission schemas differ between platforms and are not migrated; the customer assigns GoHighLevel roles post-migration.