Migrate from Axelor CRM to Mailchimp

Axelor Third Parties map to Mailchimp Members within an Audience. The Third Party name maps to the Member's Full Name field; email maps to email_address; address fields map to Mailchimp's address merge fields (ADDR1, CITY, STATE, ZIP, COUNTRY). We use email as the dedupe key during import. Third Party type (customer vs prospect) is preserved as a custom merge field or as a Tag for segmentation.

Axelor Contact records linked to a parent Third Party map to Mailchimp Members with the contact's email, first name, last name, and phone. The parent Third Party relationship is resolved by matching the Third Party email as the organization identifier in Mailchimp. If no matching Third Party exists in the source export, we create the Contact as a standalone Member.

Axelor Leads map to Mailchimp Members within the target Audience. Lead status (New, Assigned, Qualified, Converted) maps to a custom merge field or a Tag for segmentation. Converted Leads (those converted to Third Parties in Axelor) are reconciled against the Third Party export and imported as Members only once, avoiding duplicate records.

Axelor Agency records have no direct Mailchimp equivalent. We export the Agency list and create each Agency as a Mailchimp Tag. The Lead-to-Agency many-to-many junction export is resolved by applying multiple Tags to each Member based on their agency assignments. The customer selects the naming convention (Agency name as tag, numeric code as tag) during scoping.

The many-to-many relationship between Leads and Agencies is resolved by exporting the junction records and applying the corresponding Tags to each Member at migration time. If a Lead is assigned to Agency A and Agency B, both Tags are applied to that Member's profile in Mailchimp.

Axelor notes linked to Third Parties and Contacts migrate as Mailchimp Member notes. We preserve the original note text, the note author (extracted from the Axelor user record), and the creation timestamp. Notes are imported via the Mailchimp Members Notes endpoint after the Member records are created.

The recurrent revenue amount and period fields on Axelor Opportunities exist only when the 'Manage recurrent revenue on opportunities' CRM setting is activated. We detect this configuration during scoping and, if present, create custom merge fields in Mailchimp to carry the recurring amount and period values. These fields serve as reference data only since Mailchimp has no opportunity tracking.

Axelor Opportunities track sales pipeline with stages, expected amounts, and revenue dates. Mailchimp has no opportunity or deal tracking object. Opportunities are excluded from migration scope. We document the pipeline stages, stage probabilities, and revenue figures in a written summary so the customer's admin can reference them during planning or when selecting a downstream CRM if opportunity tracking is required.

Axelor Studio custom objects defined in XML and compiled as JPA models require schema inspection during scoping. If the custom object has a direct email-address field, we create a custom merge field in Mailchimp to carry the data. If it does not have an email field, we flag it as a non-migratable reference object and document its schema for manual entry or a separate tagging campaign.

Axelor user records include roles, organizational structure, and access permissions. Mailchimp does not have a user management or permission model equivalent to Axelor's role-based access. User records are not migrated. We document the owner assignment on each Third Party, Contact, and Lead so the customer can assign Members to Mailchimp user accounts manually post-migration if team-based access control is needed.