Migrate from Synerise to Odoo CRM

Synerise Profiles map to Odoo CRM Contact records by default. For Profiles that represent unqualified prospects (low engagement score, no transaction history, no assigned sales rep), we evaluate a Lead split based on the customer's segmentation criteria. Odoo Lead-to-Contact conversion is a manual action in Odoo CRM, unlike Synerise's unified profile model. We preserve the original Synerise profile identifier in a custom field synerise_profile_id__c on both Lead and Contact for cross-system audit.

Synerise stores company data as profile attributes or Brickworks schema records, not as a standalone object. We extract distinct company names and metadata from profile attributes, deduplicate by domain, and create Odoo Partner records with company_role=company. The Profile's Partner reference is established via Partner's contact_ids (relational) or is_director flag. This is the most complex object reconstruction in this migration because it requires entity extraction from free-text profile attributes and domain-based deduplication.

Synerise Deals map directly to Odoo CRM Opportunity (crm.lead model). The dealstage property maps to Odoo's stage_id within the assigned team and pipeline. Deal amount, close date, and owner migrate as expected fields. Synerise's deal-to-company assignment resolves to the reconstructed Partner record via the partner_id field.

Each Synerise Deal pipeline's stages map to Odoo CRM stages within a Sales Team. Stage probability percentages migrate from Synerise to Odoo stage probability. We configure the Odoo pipeline kanban stages during schema setup before migration so that Deal imports land in the correct stage column.

Synerise's behavioral event types (product.view, transaction, page.visit, etc.) are aggregate signal data rather than transactional records in Odoo's model. For key lifecycle events (first_purchase, subscription_renewed, churn), we create custom fields on Contact or Opportunity to store event flags or timestamps. High-volume behavioral event logs (thousands per profile) are not individually migrated; instead, we compute summary aggregates (total events, event frequency, recency) and store them as Contact custom fields.

Synerise segments (dynamic lists based on behavioral rules) map to Odoo CRM Tags for contact classification and to Pipeline Stage membership for deal qualification. We export segment membership as boolean flags per Profile and import them as tag values on Odoo Contact. Customers choose whether to create one tag per segment or to consolidate into a smaller tag taxonomy during scoping.

Brickworks schemas define arbitrary record structures in Synerise. We audit each schema and map it to Odoo custom fields on the relevant model (Contact, Partner, Opportunity) or to a custom Odoo model if the schema has no natural Odoo equivalent. Schema field types (string, integer, date, boolean) map to equivalent Odoo field types. Schema definitions (not the records) must be recreated on the destination side before migration begins.

Synerise Catalogs contain item feeds used by AI recommendation models. Catalog items export as CSV or JSON from the Data Management API with sku, name, description, price, and custom attributes. We create corresponding Odoo product.product records, preserving sku as product.default_code and mapping catalog attributes to Odoo product template extra fields.

Synerise transaction records (created via POST /v4/transactions) map to Odoo Sale Order lines if the destination includes Odoo Sale app, or to Account Move (journal entry) records if accounting history is required. We extract line items, totals, and timestamps and resolve product references to the migrated product.product records.

Synerise campaign definitions (email, SMS, push, WhatsApp) with audience rules and scheduling export via the Campaigns API. Odoo CRM does not have a native multi-channel campaign execution engine. We import campaign names and configurations as CRM tags on the Contacts that were in each campaign audience, and document the campaign structure in a written handoff so the customer's admin can rebuild in Odoo Email Marketing or a third-party marketing automation tool.

Synerise profile tags export as true/false string values per profile. We consolidate the full tag vocabulary and create Odoo CRM tags from the distinct tag names, then apply them to the corresponding Contact records. Tags with high cardinality (hundreds of unique values) are audited for consolidation during scoping.

Synerise Owners (assigned sales reps and marketers) map to Odoo User records by email match. We extract every distinct owner_id from Profile, Deal, and Engagement records and match against the Odoo destination User list. Any Synerise Owner without a matching Odoo User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Synerise AI recommendation configurations (personalized, visual similarity, last seen, top items) are trained on catalog feeds and profile event history using Synerise's proprietary embedding models. These models are not exportable. We export recommendation configuration metadata (thresholds, item feed references, display rules) as JSON in the migration manifest and document that Odoo does not have a native equivalent; the customer must implement a replacement recommendation engine (e.g., Odoo eCommerce product_cross_sell or a third-party recommendation service) and retrain on migrated catalog images.

Synerise Automation Workflows (trigger nodes, conditions, action chains for email, SMS, push, WhatsApp, webhook) are fire-and-forget by design. We export workflow definitions as JSON (node graphs, trigger conditions, action configurations) and document which workflows were active at migration cutover. Odoo Automations use a different model (server actions, scheduled actions, based on ir.cron) and the customer's admin must rebuild them post-migration. Any time-sensitive workflows (drip sequences, time-decayed offers) will have gaps during the re-activation window.