Migrate from Optimove to Odoo CRM

Optimove Customer records map to Odoo Partner records, which serve as both Contact and Company depending on the is_company flag. We map Customer name to Partner name, email to partner email fields, phone to partner phone, and address fields to Odoo's address fields. The CustomerID becomes an external identifier on the Partner record for reference reconciliation. For B2B customers with company hierarchies, we evaluate whether the Customer represents an organisation (is_company=True) or an individual contact at an organisation (is_company=False) based on available Optimove attributes.

Optimove custom attributes (up to 50 total across all input methods) map to Odoo Contact extra fields. We audit current Optimove attribute counts during discovery and flag any that exceed Odoo's practical attribute capacity per contact. Standard attributes (first name, last name, email, phone, address) map to Odoo standard fields; remaining custom attributes map to ir.model.fields custom fields on res.partner. Attributes added via Optimove's real-time API can only be updated via UpdateCustomerAttributes in Optimove, so we capture the current snapshot via Data Share SQL views before migration.

Optimove Lifecycle Stages (subscriber, lead, MQL, SQL, customer, evangelist, etc.) have no native Odoo equivalent. We preserve stage assignments as Odoo contact tags (res.partner.category) with a naming convention that maps to the original Optimove stage name (e.g., tag: Optimove_Lifecycle_Customer). For reporting continuity, we also create a custom selection field lifecycle_stage__c on res.partner that stores the original stage value as a string. Historical stage transition data from Migration Explorer exports becomes a set of CRM log notes on each Contact.

Optimove Target Groups are dynamic customer segments built from attribute rules. We export the customer membership lists and recreate them as Odoo CRM tags or Odoo saved filter groups (Smart Groups). Complex nested rules with multiple AND/OR conditions are documented in the automation inventory for manual rebuild in Odoo's domain filter system. For segments with fewer than 5,000 members, we can pre-populate tag membership by processing the exported membership list against the migrated Contact IDs.

Optimove's proprietary predictive scores and OptiGenie AI next-best-action recommendations are generated within Optimove's modeling engine and have no standard equivalent in Odoo. We export raw numerical scores from Optimove Data Share where accessible and store them as read-only custom float fields on the Contact record (e.g., predictive_churn_score__c, predictive_clv__c). These values serve as historical baselines for the customer to reference when rebuilding predictive models in Odoo using third-party BI tools or custom Python logic. The underlying model logic, confidence intervals, and OptiGenie recommendations cannot migrate.

Optimove campaign metadata including name, type, channels, and scheduling migrates to Odoo CRM Campaign records. The campaign name, start date, and target audience size transfer directly. Campaign channels (email, SMS, push, web, WhatsApp) are stored as tags or custom fields on the Odoo Campaign. Campaign journey orchestration logic and automation rules cannot export from Optimove and must be manually recreated in Odoo; we deliver a written campaign inventory document listing every active campaign with its configuration for the customer's admin to reference.

Historical campaign performance data including sends, opens, clicks, conversions, and control group metrics from Optimove Data Share migrates to Odoo CRM Campaign Member records linked to the relevant Contact. Engagement metrics are linked to CustomerIDs for downstream attribution. We store aggregated campaign performance data as CRM log notes on the Campaign record and detailed per-contact engagement as CRM Campaign Member status history. Control group membership assignments transfer as tags on the relevant Contact records.

Optimove Control Group membership transfers as a dedicated tag on the relevant Contact records (e.g., tag: Campaign_Control_Group_[CampaignName]). This preserves the control group assignment for accurate post-migration campaign ROI calculation. We map control group percentages and test group sizes from Optimove's Data Share exports into a Campaign log note documenting the original test configuration.

Optimove's multi-brand architecture structures customer data by customer network and brand, each potentially having independent database schemas and attribute definitions. We identify all separate networks during discovery, map each to an appropriate Odoo Company (within a single database) or a separate Odoo database instance. Schema differences between networks within the same Optimove tenant require separate mapping workstreams. Each Odoo Company gets its own partner records, warehouse, and reporting context, and contacts are scoped to their parent company using the company_id field on res.partner.

Optimove user accounts and roles listed via the platform admin interface map to Odoo Users. Role permissions and access levels require manual recreation in Odoo because Optimove's permission model is proprietary and not exportable. We extract user name, email, and role names from Optimove's admin export and map active users to Odoo User records with matching login email. The customer's Odoo admin rebuilds access rights using Odoo's internal user groups and access rights menus.

Optimove is a data and orchestration platform, not a content management system. Media assets used in campaigns (images, HTML email templates, creative files) are stored in connected ESPs or content tools, not in Optimove itself. We do not migrate media assets. The customer identifies which external content systems (e.g., Mailchimp, SendGrid, custom ESP) hold the campaign creative and reconnects those systems to Odoo's email marketing module post-migration.

Optimove does not expose a documented Custom Objects API equivalent to standard CRM objects. Only Customer-level custom attributes are supported via the API, not independent object types. We cannot migrate Optimove custom object data because no export endpoint exists for those records. If the customer has custom objects that contain essential business data, we document the object schemas and field definitions during discovery so the customer can recreate them as custom Odoo models (ir.model and ir.model.fields) or as Odoo Studio custom fields on res.partner in a separate development engagement.