Migrate from Anthill CRM to Odoo CRM

Anthill Enquiry records map to Odoo CRM Lead. The Anthill enquiry status and associated workflow stream become the Odoo Lead stage and crm_team. We extract the workflow stream definition during discovery to build the stage mapping before the first import run. The original Anthill enquiry identifier is preserved in a custom field anthill_enquiry_id for audit and reconciliation. All standard Lead fields (name, email_from, phone, partner_name for company, description for notes) migrate directly; picklist values not present in Odoo are flagged for the customer to create before import.

Anthill Customer records hold contact and company data in a single object. We split this into Odoo Contact (the person) and Account (the company) by using the contact_name and company_name fields from Anthill if available, or by parsing the customer_name field for a name-company split pattern. The Account is created first so that the Contact's partner_id (Account) reference is satisfied at insert time. Any Anthill customer with no company affiliation becomes a standalone Contact without an Account parent.

Anthill Workflows define the stages a customer interaction passes through and assign actions to teams (Sales, Admin, Support). Each named workflow stream maps to an Odoo CRM pipeline, and each workflow state maps to an Odoo stage within that pipeline. The team-level action assignments map to Odoo Sales Team membership and the responsible_user_id on each Opportunity. We generate a workflow-to-pipeline mapping document during scoping and apply it before the first Opportunity import. If Anthill workflows have conditional branching, we map the primary branch only and flag conditional paths for the customer to configure manually in Odoo.

Anthill Activities tied to Enquiries and Customers map to Odoo Note records linked via mail.activity to the parent Lead or Contact, and to Task records where a discrete action item with a due date exists. Anthill does not expose a documented activity-history bulk endpoint, so we pull activity records via per-Enquiry API calls and batch them by object type. Activity timestamps and content text migrate directly; attachment handling depends on whether the activity has linked files in Anthill's storage layer.

Anthill organises actions by team (Sales, Admin, Support) and assigns record owners to individuals within those teams. We map Anthill team names to Odoo crm.team records and Anthill owner email addresses to Odoo res.users by email match. Any Anthill owner without a matching Odoo User is placed in a reconciliation queue for the customer's admin to provision before record import proceeds. Team-level assignments without a specific owner map to the Odoo crm.team record directly.

Anthill supports custom fields per object but does not publish a field reference catalogue. We pull the actual field inventory by introspecting API responses during discovery, then provision equivalent custom fields in Odoo via the Settings > Technical > Custom Fields interface before import. Picklist-type custom fields map to Odoo selection fields with values created under Settings > Technical > Selection Values. Fields with no Odoo equivalent are flagged in the migration report for the customer to decide whether to carry forward or archive.

Anthill represents deal progression as workflow stream states rather than a column-based pipeline. We extract each workflow's stage names and statuses and map them to Odoo crm.stage records within the relevant crm.team pipeline. Stage probability values migrate to the probability field on each Opportunity record. Stage sequence ordering is preserved via the sequence field on crm.stage.

Anthill live dashboards are configuration files within the platform's internal visualisation engine and are not exposed through the SOAP or JSON API. We do not attempt an API export because one does not exist. Instead, we perform a dashboard audit during discovery: we document the layout, metrics, filters, data sources, and team-level access rules from the live Anthill system and deliver a written dashboard specification that the customer's Odoo administrator uses to rebuild the most critical dashboards using Odoo Studio or the reporting interface post-migration.

Anthill automations are scoped to workflow state transitions and reference Anthill-specific contact properties and action types. They cannot be directly migrated to Odoo automated actions because the trigger conditions, action types, and field references differ fundamentally. We deliver a written automation inventory that documents each Anthill automation's trigger event, conditions, actions, and team assignment, with a recommended Odoo Automated Action or server_action equivalent. Rebuilding automations in Odoo is a post-migration configuration task performed by the customer's admin or an Odoo implementation partner.

Anthill User records and their team assignments map to Odoo res.users and crm.team membership. We resolve by email match against the Odoo User table. Inactive Anthill users map to inactive Odoo users to preserve historical assignment without granting active system access. Team membership records are created in the Odoo crm_team_member table during migration.

File attachments associated with Anthill Enquiries (such as uploaded documents, signed forms, or referenced files) migrate as Odoo ir.attachment records linked to the parent Lead via res_model and res_id. We pull attachment URLs from the Anthill API where exposed and download them to local storage before uploading to Odoo via the /web/binary/upload_attachment endpoint. Attachments without a reachable URL in Anthill are flagged in the migration report for manual handling.

If the Anthill instance includes linked quote or invoice data (available on Anthill Professional and Enterprise tiers), these map to Odoo sale.order and account.move records respectively. Quotes migrate as sale.order in draft state for the customer's admin to review before sending. Invoices migrate as account.move records in the appropriate state (draft or posted) depending on the Anthill invoice status. The customer_name and product references are resolved through the Account and product.product lookups created in the earlier mapping phases.