Migrate from Zymplify to Odoo CRM

Zymplify Contact records with standard fields (name, email, phone, role, company association) map directly to Odoo CRM Partner records in customer mode, with phone and mobile mapped to phone and mobile fields. Where Zymplify uses a separate Contact object, Odoo uses Partner with a type field set to 'contact' for individuals; the associated Company maps to a separate Partner in company mode with the contact linked via child_ids. Enrichment provenance from Zymplify's CDP hub is carried as custom Char fields (e.g., enrichment_source__c) rather than native metadata.

Zymplify Company records map to Odoo Partner records with type='company'. The company domain becomes the website field and is used as a dedupe key during import. Bombora intent scores, G2 Buyer Intent signal levels, and Zymplify's intent spike timestamps are carried as custom Float or Char fields on the Partner record (e.g., bombora_score__c, g2_intent_topic__c, intent_spike_date__c). The original intent signal data is migration metadata rather than a native Odoo object.

Zymplify Deals map to Odoo CRM Lead/Opp objects. Pipeline stages are customisable per account in Zymplify; we map stage names 1:1 to Odoo stage names within the relevant sales team pipeline. Deal value, close date, and probability transfer to Odoo's expected_revenue, date_deadline, and probability fields. Odoo's stage-based kanban view mirrors Zymplify's pipeline view, reducing training friction.

Zymplify Sales Cadences are outreach sequences combining email steps, delays, and task actions. Odoo has no native cadence equivalent. We document each cadence's step sequence, delay logic, and action types as a rebuild specification for the customer's admin, and we create CRM phonecall and note records for any completed or in-progress cadence steps that represent actual customer touchpoints. The rebuild target in Odoo is Automated Actions triggered by stage changes or partner tags.

Zymplify Marketing Workflows use triggers, conditions, and actions in a visual builder. Odoo Automated Actions are server-side actions driven by ir.actions.server records with Python domain expressions. We document each Zymplify workflow's trigger, conditions, branch logic, and action outputs as a requirements specification; the customer's admin rebuilds them as Odoo Automated Actions or via the workflow module. Workflow automation does not migrate as code.

Zymplify health scores and churn risk indicators are platform-native calculations with no Odoo equivalent. We extract raw health signals (engagement frequency, renewal proximity, support ticket count) as custom Float and Date fields on the Partner record (e.g., health_score__c, churn_risk_indicator__c). The scoring model itself does not migrate; the customer admin rebuilds it in Odoo using Automated Actions or a dedicated custom module.

Zymplify's CDP hub manages contact deduplication and enrichment provenance. We carry the deduplication decisions (merged record IDs, master record flags) and enrichment source data as custom fields on the Partner record (e.g., cdp_merge_master__c, enrichment_provider__c, enrichment_date__c). The cleansing workflow itself is not migratable; it must be rebuilt in Odoo using duplicate detection rules or a third-party data quality app.

Zymplify custom fields across all object types do not have a publicly documented export schema. We discover the custom field inventory during the discovery phase by querying Zymplify's API for field metadata, then create matching custom fields in Odoo via the Settings > Technical > Fields interface before data import. Field types are mapped from Zymplify types to Odoo field types (text to Char, number to Float or Integer, date to Date, checkbox to Boolean, multi-select to Char with comma-separated values).

Zymplify User records include role, hub assignment, and ownership relationships. We map active users to Odoo User records by email match. Hub assignments (Prospecting, Marketing, Sales, Success) are preserved as custom Char or Selection fields on the User record because Odoo's internal categories do not map directly to Zymplify's four-hub model. Owner relationships on Deals and Contacts are resolved via User email lookup at migration time.

Tags applied to Contacts and Companies in Zymplify are platform-native. We export them as a comma-separated custom Char field on the Odoo Partner record (tags__c). Odoo's messaging system supports tags on communication records but not on Partner records natively; the customer chooses between storing as a custom Char field or rebuilding tagging taxonomy using Odoo tags on CRM Lead tags. This decision is made during scoping based on how tags are used in reporting.

Bombora intent scores and G2 Buyer Intent signal data are Zymplify-native metadata attached to Company records. They cannot be exported as structured objects via a documented Zymplify API. We extract signal metadata as custom fields (bombora_intent_score__c, g2_topic_intent__c, signal_provider__c, signal_date__c) on the Partner record. Intent data has no Odoo equivalent and functions as enrichment provenance for the customer's admin to act on manually or rebuild within Odoo's reporting tools.

Zymplify engagement records are split by type: call engagements map to Odoo crm.phonecall (or calendar.event for scheduled calls), email engagements map to mail.message records linked to the Partner, meeting engagements map to calendar.event with attendee relations, and task engagements map to mail.activity records. Engagement timestamps and disposition data transfer to custom fields on the target record. Parent record resolution (linking engagements to the correct Partner) is resolved via email match on the Contact and Company records before migration.