Migrate from Ometria to Odoo CRM

Ometria Contacts migrate to Odoo res.partner records with partner_type set to 'contact'. The Ometria contact identifier is stored as a legacy_id field on the res.partner for audit and cross-reference. Email, phone, and address fields map directly. Custom customer attributes stored on the Ometria contact profile map to Odoo custom fields on res.partner; we resolve Ometria field types (integer, string, boolean, date) to Odoo field types (char, integer, boolean, datetime) before schema provisioning. Ometria contacts with a company association map to a parent res.partner account record.

Ometria Company records migrate to Odoo res.partner with partner_type set to 'company'. The Ometria company domain becomes the Website field on the res.partner. Company records are created before Contact import so that the parent_id relationship is satisfied at Contact insert time. Store-level data attached to a Company in Ometria maps to address records (child res.partner with type='delivery' or 'invoice') or to a separate store configuration depending on the customer's Odoo setup.

Ometria Deals migrate to Odoo crm.lead with type='opportunity'. The Ometria dealstage property maps to an Odoo CRM Stage; we pre-create the destination stages during schema setup. Pipeline assignment from Ometria maps to an Odoo Sales Team (crm.team) or a custom stage grouping. Closed-Lost and Closed-Won reasons from Ometria become custom fields on crm.lead for loss reason tracking. Deal amount and expected close date migrate directly.

Ometria Segments are rule-based dynamic groups that do not export as static membership lists with complete segment logic. We export segment membership (the set of contact IDs belonging to each segment at migration time) and map them to Odoo res.partner.category tags or a custom multi-select field. The segment definition logic (rule builder) does not migrate and must be rebuilt in Odoo using Odoo Studio, custom Python logic, or a third-party segmentation app.

Ometria Lifecycle Programs are multi-step automation journeys with event triggers, delays, and conditional branches. These do not migrate as automation code. We export program structure as a written inventory document listing every program name, trigger condition, step sequence, and conditional logic. The customer's Odoo admin rebuilds programs using Odoo Email Marketing, automation rules, or a marketing integration (Klaviyo, Mailchimp via Odoo app). Lifecycle stage values on contacts migrate as static res.partner.category tags for reporting.

Ometria broadcast campaigns (one-time email sends to a list or segment) cannot be migrated as live campaigns. We export broadcast template HTML and campaign history (send date, list size, delivery metrics as a report file). Email templates migrate as content assets requiring rebuild in the destination email marketing tool. Sending logs and individual engagement records (opens, clicks) migrate as data files for reconciliation purposes only.

Ometria event schema is customizable per account. We map event names and property structures, flagging any events with non-standard schemas. Purchase events (order_placed) may map to Odoo sale.order records; behavioral events (page_viewed, email_opened) map to custom fields on res.partner if they represent customer attributes, or to crm.lead notes for lead-scoring purposes. Event logic and triggering conditions do not migrate.

Custom fields on Ometria contact profiles (VIP flag, lifetime value, brand preferences, loyalty points) migrate to Odoo custom fields on res.partner. We resolve Ometria field types to Odoo field types: Ometria Integer becomes Odoo integer or float depending on the value; Ometria Boolean becomes Odoo boolean (checkbox); Ometria Date becomes Odoo date. Custom fields are provisioned via Odoo Studio or metadata XML before data import. Fields are scoped to the res.partner model; fields referencing deprecated Ometria integrations are flagged for the customer to confirm retention.

Ometria order records (purchase history, revenue attribution, attribution model data) migrate to Odoo sale.order if the Odoo Sales app is in scope. Revenue figures may differ from Google Analytics by 15-20% due to Ometria's own attribution model; we flag this discrepancy before final cutover and validate totals against Ometria's native reports rather than external analytics. Order-level coupon and promotion data from Ometria events maps to custom fields on sale.order.line.

Ometria suppression lists hold contacts blocked from receiving email for compliance or deliverability reasons. These migrate to Odoo mail.blacklist, which is the standard mechanism for blocking email delivery in Odoo. We export the full suppression list including the reason field if present. GDPR consent records (opt-in timestamp, opt-in source) migrate to res.partner as a consent tracking field or mailing.contact record. Applying the suppression list at migration time ensures no migrated contacts receive unexpected email after cutover.

Ometria stores represent individual retail locations integrated as data sources. Store profiles and location metadata migrate to Odoo as address records (res.partner with type='delivery') or as stock.warehouse records if inventory is managed per location. Store-level suppression rules migrate as location-specific blacklist entries. Store-level loyalty program associations do not migrate and must be rebuilt in Odoo Loyalty or a third-party loyalty app.

Subscribers are Ometria contacts with explicit opt-in status. Consent records are migration-critical for GDPR compliance. We preserve subscription status, consent timestamp, and opt-in source, mapping to Odoo mailing.contact if the Odoo Email Marketing app is in scope, or to custom fields on res.partner (opt_in_date, opt_in_source). Unsubscribed status from Ometria suppression list is enforced via mail.blacklist entry at the destination.