Migrate from Customer.io to Odoo CRM

Customer.io People profiles map to Odoo res.partner records. The userId becomes partner_ref or the external ID field; email maps to email; name maps to name. Anonymous traits (city, country, plan tier) map to custom fields on res.partner that we create via Odoo Studio or XML data migration. The full trait JSON is preserved as a serialized field for compliance auditing. Active-to-inactive ratio is calculated during scoping and inactive profiles can be flagged as archived partners rather than imported as active records to keep the Odoo partner table clean.

Customer.io event history has no direct Odoo equivalent, so we represent each event as a mail.activity record linked to the migrated Contact. Event name becomes activity.activity_type_id (or a custom activity type); event properties become the activity.note field in structured JSON; sentAt/receivedAt becomes activity.date_deadline and activity.create_date. This preserves the timeline and properties but loses the event-as-first-class-object granularity. Customers who rely heavily on event segmentation in Customer.io should rebuild that logic using Odoo Lead Automation rules and contact tags post-migration.

Customer.io dynamic Segments are rebuilt in Odoo as a combination of contact tags and custom Lead scoring fields. During migration we export each segment's rule criteria as a structured JSON object, then create equivalent Odoo tags (using the contacts_base module or res.partner.category). Segment criteria that rely on event conditions are translated into Odoo Lead Automation rules referencing the activity log entries created during event migration. Customers receive a Segment-to-Tag mapping document as part of the handoff.

Customer.io Campaigns do not have a native Odoo CRM equivalent because Odoo has no multi-step journey or campaign automation object. We export campaign structure (name, trigger type, entry conditions, channel assignments, wait steps) as a structured JSON document and map campaign entry to Odoo pipeline stage assignment or a Contact tag identifying the campaign source. The customer's Odoo admin rebuilds multi-step campaign logic using Odoo Lead Automation (crm.lead.automation) or Odoo Marketing (if licensed) post-migration.

Historical Broadcast sends are represented in Odoo as Contact records tagged with the broadcast name, with a mail.message note recording the send timestamp and approximate audience size. Broadcast content and targeting criteria are exported as structured records in the broadcast audit document. API-triggered broadcast rate limits (1 request per 10 seconds on Customer.io) do not apply in Odoo; any automated send logic rebuilds as Odoo Lead Automation or a custom mail.mass_mailing configuration.

Customer.io Custom Objects with object_type_id = company or account map to Odoo res.partner records where is_company = True. The custom object ID becomes the external ID; custom fields on the object map to custom fields on the res.partner record. If the customer uses multiple Custom Object types, each maps to a separate res.partner category or a custom res.partner.subtype field. Relationships between People and Companies in Customer.io are preserved as parent_id links on the res.partner record in Odoo.

Customer.io transactional message templates (receipts, password resets, shipping notifications) map to Odoo mail.template records. We export template content, trigger conditions, and the unsubscribe bypass flag. Delivery logs (sent, delivered, undeliverable, bounced) map to mail.mail records with mail.mail.state preserved. Note that Customer.io's message retention setting may redact some transactional content; we flag any redacted payloads before export and mark those mail.mail records as content_redacted in Odoo.

Delivery status for emails sent from Customer.io maps to Odoo mail.mail records. Sent, delivered, bounced, and undeliverable statuses migrate with the status code preserved. Open and click tracking data does not have a native Odoo equivalent and is exported as structured metadata on the mail.mail record rather than a tracked engagement event.

Customer.io trait key-value pairs (strings, numbers, booleans, arrays, nested objects) map to Odoo res.partner custom fields created via Odoo Studio or a data migration CSV. Flat traits map directly; nested objects are flattened using a dot-notation convention (e.g., subscription.plan_name becomes x_subscription_plan_name). Arrays (e.g., enabled_channels) become Odoo char or many2many fields depending on the customer's use case, decided during scoping.

Customer.io email engagement records map to Odoo mail.message records linked to the res.partner. Body, subject, send timestamp, and delivery status migrate. Open and click tracking are exported as structured metadata on the message. Email threads that span multiple Customer.io sends are represented as a sequence of mail.message records ordered by timestamp.

Customer.io SMS engagement records map to Odoo mail.message records with a custom sms_channel field identifying them as SMS rather than email. Body, recipient phone number, send timestamp, and delivery status migrate. Odoo SMS delivery receipts are not natively supported in the Community edition; SMS migration is scoped for Odoo Enterprise or Online with iap_sms configured.

Push notification history migrates as mail.message records flagged as x_push_notification = True, recording the message body and send timestamp. We do not re-send push notifications in Odoo because Odoo CRM has no native push notification capability and device tokens from Customer.io cannot be transferred to any other provider. Customers requiring push notifications post-migration must implement a separate push service (Firebase, OneSignal, etc.) and do not migrate device tokens as part of the CRM data migration scope.