Migrate from Agillic to Odoo CRM

Agillic Recipients are flat person records with no mandatory company parent. Odoo requires every Contact to belong to a Company. We group Recipients by email domain to create parent Company records first (example.com becomes a Company named 'example.com Domain Group'), then link each Contact to its parent via the contact_ids relationship. Recipients without an identifiable domain become Contacts without a parent Company. This is the foundational step — all subsequent Contact imports depend on the Company parent existing.

Standard Agillic recipient fields (email, first name, last name, phone, address, birthday) map directly to Odoo Contact fields. All custom recipient properties defined by the client are enumerated during discovery and pre-created as Odoo custom fields on the Contact model via Studio or a data migration module before any Contact records are imported.

Agillic send, open, and click events migrate as Odoo Task records with a custom activity_type field (email_sent, email_opened, email_clicked). The Flow Execution ID preserved in Activity Exports links each Task to a custom flow_execution_ref field on the Contact for journey reconstruction. We set Task create_date to the original Agillic activity timestamp to preserve timeline order.

Agillic SMS delivery events migrate as Odoo Task records with a custom sms_delivery field. Delivery status (delivered, failed, undelivered) maps to a custom sms_status__c picklist on the Task. If the SMS content body is needed, it stores in the Task description field.

Agillic event triggers (Flow Entry events, custom events) migrate as Odoo Event records. The event name maps to Event Subject; event timestamp maps to Event StartDateTime. Custom event properties from Agillic store in custom fields on the Odoo Event model.

Agillic meeting activities with confirmed attendee lists migrate as Odoo Event records. StartDateTime, EndDateTime, Location, and attendee Contact references map directly. Meeting title maps to Event Subject.

Agillic notes attached to Recipients migrate as Odoo Note records linked via mail.message or ir.attachment to the parent Contact. Note body and create date migrate verbatim; author is resolved via owner email to the Odoo User.

Global Data Tables in Agillic are custom relational structures referenced in Flows. If a table has few columns and fewer than 1,000 rows per Recipient, we flatten it into custom fields on the Contact model. If a table has complex columns, foreign keys, or high row volume, we create a custom Odoo model via Python module with a many2one relationship to Contact, then import all rows. This decision is made during discovery based on table count and row volume.

Agillic Flow names and associated Flow Execution IDs are preserved as Contact tags (one tag per unique Flow name) and stored in a custom field flow_execution_ids__c as a semicolon-separated list. This provides a referenceable audit trail of which Flows touched each Contact without requiring Odoo to understand Agillic Flow logic.

Agillic Flows cannot be exported as portable definitions. We deliver a written inventory of every active Agillic Flow with its trigger event, conditions, actions, and wait steps. The customer or an Odoo implementation partner rebuilds each Flow as Odoo Server Actions and Action Rules. This is explicitly not a data migration — it is a documented handoff for manual rebuild.

Agillic email, SMS, and push templates export as content files with dynamic field markers. We map template content to Odoo Email Template records, replacing Agillic's Liquid-style dynamic markers with Odoo's qweb-templating syntax. HTML templates require content refactoring; we document all unmapped dynamic fields for the customer's admin to configure in Odoo Studio.

Agillic's Recipients Export feature produces a snapshot file of all recipient records and current field values. We use this as a baseline reconciliation source against the API export, identifying records that differ between the two data sources and flagging discrepancies before import begins.

Agillic Owners map to Odoo User records. We resolve by email match against the destination Odoo User table. Any Owner without a matching User is held in a reconciliation queue for the customer's admin to provision before Contact and Deal import resumes.

Agillic audience segments (Google and Meta activation lists) are captured as membership records. We recreate equivalent segments as Odoo Contact tags (one tag per segment name) and document the membership criteria so the customer can rebuild segment logic in Odoo Email Marketing or a third-party activation tool.

Agillic Content Blocks are modular HTML and text fragments used across templates. We export block content and metadata, then document the replacement strategy: content blocks map to Odoo Email Template snippets (ir.ui.view fragments) or an external content management reference. HTML content blocks require refactoring for Odoo's qweb templating engine.