Migrate from Cordial to Odoo CRM

Cordial Contacts map to Odoo res.partner records. We export the flat attribute schema (email, first_name, last_name, phone, address fields) and map each standard Cordial contact attribute to an Odoo custom field on res.partner. Array-type attributes (tags, favorite colors, behavioral lists) require schema normalization: we flatten to delimited strings or create a related res.partner.tag record with a many2many relationship, agreed upon with the customer during scoping. The res.partner record is the parent for all downstream lookups.

Cordial's unlimited custom contact attributes (string, number, geo, array types) map to Odoo custom fields on res.partner. We create each custom field via Odoo Studio or Python model migration before data import. Array-type attributes require the customer to choose between a multi-value char field, a dedicated res.partner.tag relation table, or separate normalization. Geo-type attributes (latitude, longitude) map to Odoo's res.partner partner_latitude and partner_longitude fields or to a separate geo.point relation.

Cordial Lists (static contact sub-collections) map to Odoo res.partner.category records (tags) with a many2many relation to res.partner. Each Cordial list becomes a category record with the list name as the tag name, and list membership migrates as partner-category associations. If the customer uses Odoo Email Marketing, we alternatively map to mailing.contact for precise opt-in audience management.

Cordial Channels (email, SMS opt-in status and preferences per contact) map to Odoo res.partner fields: email becomes email, email_cohorts or opt-out flags become opt_out, and mobile preferences become mobile with SMS-specific opt-in mapped to a custom field cordialsms_optin__c. We export channel preferences as separate boolean fields and flag any non-standard channel types that have no Odoo equivalent.

Cordial Products with nested variant JSON arrays require unpacking. Each Cordial product record generates one product.template in Odoo. Each variant within the Cordial variants array (color, size, SKU pairs) generates a separate product.product record linked to the template via product.attribute.value. We preserve the parent Cordial product ID as an external reference field for reconciliation. If Odoo does not already have the relevant product attributes (color, size) defined, we create them during the migration schema setup.

Orders are not a native Cordial object and require pre-migration schema discovery. We identify order-related custom attributes and custom event types (purchase events) during discovery, extract order records from the behavioral event log, and map them to Odoo sale.order and sale.order.line. Customer association resolves to the res.partner record; product association resolves to product.product via SKU lookup; pricing and quantity map directly. This phase is scoped separately because order data location varies per customer implementation.

Cordial Companies stored in the Companies collection map to Odoo res.partner records with company_type = company. Address, domain, and industry fields map to standard Odoo partner fields. A separate res.partner contact record is created under the company partner for each related contact record, linked via parent_id. If Cordial Company is used only for enrichment and not as a separate collection, the company data is extracted from the contact attributes and applied to the partner record directly.

Cordial Segments (dynamic rule-based audiences) do not have a direct Odoo equivalent in the standard CRM module. We export segment definitions as rule summaries and document which contacts currently match each segment. For static lists we create res.partner.category records; for dynamic segments we document the rule logic so the customer's admin can implement Odoo Search Filters or domain filters on a saved search as the equivalent.

Cordial Contact Activities (opens, clicks, purchases, custom events) map to Odoo mail.activity records linked to res.partner. We export activity data via the Contact Activity Export API with time-range and event-type filters. Each activity type (email_open, purchase, custom_event_name) becomes an activity with activity_type_id set to a custom Odoo activity type created during schema setup. ActivityDate maps to date_deadline and create_date preserves the original timestamp. If the customer uses the Odoo CRM module heavily, mail.activity provides a workable activity timeline; note that Odoo does not natively support the granular A/B engagement metrics that Cordial captures per message.

Cordial Owners (sales reps assigned to contacts and products) map to Odoo res.users by email match. We extract every distinct owner referenced in the Cordial export, match against the Odoo destination User list, and flag any owner without a corresponding Odoo user for the customer's admin to provision before the migration proceeds. user_id on res.partner is set during import to maintain rep assignment.

Cordial Message Analytics (opens, clicks, bounces, unsubscribes) migrate to Odoo mail.message records linked to the relevant res.partner. We preserve aggregate metrics (open count, click count, bounce status) as custom fields on the partner record. Experiment results (A/B and multivariate test outcomes) are explicitly not API-exportable from Cordial and cannot be migrated programmatically; we flag this gap during discovery and recommend exporting experiment data from the Cordial UI before cutover.

Cordial Programs (automation sequences and campaign logic) are not API-exportable. We deliver a written inventory of every active Program including trigger events, conditions, delay rules, and action sequence with a recommended Odoo Server Action or CRM Activity Plan equivalent. The customer's Odoo admin or implementation partner rebuilds the automations post-migration. We do not execute automation logic inside the migration scope.