Migrate from Delivra to Odoo CRM

Delivra Contacts map to Odoo Lead for unqualified prospects and Odoo Contact for qualified buyers or existing customers. We use the Delivra contact's lifecycle stage, subscription status, and campaign engagement level to determine the split. Contacts with no deal association and low engagement scores map to Odoo Lead; contacts with active deal associations or high engagement scores map to Odoo Contact with an Account reference. Original Delivra contact properties (custom fields, tags, lead score) migrate as custom fields on both Odoo Lead and Contact objects.

Delivra Custom Tables with 1:1 relationships to contacts flatten into custom fields on the Odoo Lead or Contact object. 1:many relationships (one contact, many subscriptions) denormalize into a one-to-many Odoo custom model with a Many2one link back to the Contact. Many:many relationships (many contacts, many events) use an intermediary link table model in Odoo with two Many2one fields. We extract the full Delivra table schema during discovery, design the destination Odoo model structure, and build the custom fields and models in Odoo before any data loads. This adds one to two weeks to the migration timeline for accounts with more than three active Custom Tables.

Delivra Campaign records map to Odoo CRM Lead records with a campaign_name custom field carrying the original Delivra campaign title. Campaign targeting criteria (segment definitions) are translated to Odoo domain filters on the Lead object. If the Delivra campaign has associated Opportunities or revenue data, those map to Odoo Opportunity records linked to the Lead via the lead_id reference. Campaign status (active, paused, completed) migrates as a custom picklist field.

Delivra segment definitions use filter conditions on contact properties and engagement behaviors. We extract each segment's criteria as a written rule set and translate it to an equivalent Odoo domain filter (stored in ir.filters) or a static Lead/Contact Group. Static groups copy the matching contact IDs directly; dynamic filters execute the domain on the Odoo side at query time. The customer chooses which approach during scoping based on whether real-time segmentation or pre-computed membership is preferred.

Delivra lead scoring models with point values assigned to contact attributes and behaviors migrate as Odoo custom integer fields (e.g., delivra_score__c) and optional computed fields that recompute from Odoo data post-migration. The scoring rules themselves (e.g., +10 for email opened, +5 for form submitted) are documented in a scoring model inventory and do not execute automatically in Odoo; the customer's admin implements them as Odoo Server Actions or Python computed field logic if desired.

Delivra Automated Workflows are visual logic constructs with triggers, decision branches, time delays, and CRM actions. These do not migrate as executable automation code because the Odoo Workflow Engine uses a different model (Python-based activities and transitions). We deliver a written workflow inventory documenting every active Delivra workflow with its trigger type, conditions, actions, and recommended Odoo Server Action or Automated Action equivalent. The customer's admin or an Odoo partner rebuilds the automations post-migration.

Delivra email templates built with the drag-and-drop editor migrate as HTML content and asset references. Complex layouts with conditional content blocks and dynamic field insertions are extracted as HTML and require re-authoring in Odoo's template editor or a code-based email template. We deliver the raw HTML output so that the customer's admin can paste it into Odoo's mail template editor. We do not re-create the visual drag-and-drop structure.

Delivra web forms migrate as form field definitions and configuration documented in a written inventory. Odoo Website supports form builders that accept the field schema (field names, types, required flags) for re-creation. Form submissions and landing page submissions that exist as contact records in Delivra migrate as CRM Leads with the original submission source noted in a custom field.

Delivra tracks clicks, opens, and engagement scores on each contact. We migrate engagement metrics as custom integer or date fields on the Odoo Lead or Contact (e.g., last_email_open_date__c, total_email_opens__c, total_email_clicks__c). Large-volume engagement event logs (thousands of per-contact events) are summarized at the contact level rather than migrated as individual activity records, because Odoo CRM's activity model is task and meeting oriented rather than marketing event oriented.

Delivra Users and their role assignments migrate as Odoo res.users records. We match Delivra users by email address against the destination Odoo instance's user table. Role assignments from Delivra (admin, editor, viewer) map to Odoo group memberships (Sales / Administration / Portal) that we configure during migration. Any Delivra user without a matching Odoo user goes to a reconciliation queue for the customer's admin to provision before record import resumes.

If Delivra's contact import included company records or if the customer used Delivra's company field, those map to Odoo res.partner records with is_company = True. Delivra company properties (industry, size, website) map to custom fields on the Odoo partner. The Odoo partner is created before any Contact/Lead import so that the Many2one reference is satisfied at the moment of insert.

Delivra's GDPR compliance fields (consent date, consent source, unsubscribe status) migrate to Odoo res.partner email fields: opt_out = True for unsubscribed contacts, and custom fields (consent_date__c, consent_source__c) carrying the original consent record. We preserve the original opt-in/opt-out timestamp so that the customer's Odoo admin can configure Odoo's mailing list rules to respect subscription preferences at migration cutover.