Migrate from Bento to Odoo CRM

Bento Contacts with strong engagement signals (multiple campaign opens, click events, or Custom Events with high-frequency properties) map to Odoo CRM Contact records. Contacts with minimal engagement or imported cold prospects map to Odoo Lead records for sales qualification follow-up. We compute this split using Bento's engagement property values and apply it during the export transform. The original Bento contact_id is preserved in a custom field for audit traceability.

Bento's flat tag taxonomy migrates to Odoo CRM's Contact Tags using the Odoo contacts.batch.import endpoint or direct SQL tag insertion via the contacts.tag model. Tags are stored as many2many relationships on the contact record. We export the complete tag list as a lookup table and apply it during import so the full taxonomy is preserved without manual recreation.

Bento custom fields with explicit data types map to Odoo ir.model.fields definitions. String fields map to char or text; number fields map to float or integer; date fields map to date; boolean fields map to boolean; choice fields map to selection. Odoo Studio can define some field types without custom addon development, but choice fields with more than 40 values require a custom addon or database-level field creation. We scope this during discovery and document any incompatible field types for manual resolution.

Bento Segments are dynamic filter rules combining contact properties and Custom Events. We export each segment definition as a structured rule document specifying the filter conditions, operator logic, and event-based triggers. These segments cannot be recreated as executable Odoo filters because Odoo's contact filtering uses a different condition model. We deliver the segment definitions as a specification document so the customer's Odoo admin builds equivalent static or dynamic groups in Odoo Contacts.

Bento campaigns are one-time email send records with subject, HTML content, and send history. We export campaign metadata (name, subject, send date, send count, open rate, click rate summary) as a structured CSV. The HTML content is exported separately for use in rebuilding the campaign in Odoo's email marketing module or an integrated email tool. Campaign performance stats are aggregate summaries only; record-level engagement history migrates separately as Custom Event data.

Bento Custom Events are behavioral signals tracked per contact with a specific property schema. Odoo CRM has no native equivalent to Bento's event tracking model. We export the event schema (event name, property names, property data types) and the full event log per contact. At the destination, these map to additional custom fields on the Contact record or to Note attachments with structured event JSON for future Odoo custom addon development. Any event properties with incompatible data types are flagged during scoping.

Bento's unsubscribed contact suppression list migrates as a separate CSV. At the destination, we insert records into Odoo's mailing.contact model with opt_out set to True. This preserves CAN-SPAM and GDPR compliance and prevents Odoo from accidentally sending to suppressed addresses. The unsubscribed list is processed before any active contact import to ensure suppression is active at cutover.

Bounced contacts export as a separate CSV from active contacts. We insert them into Odoo mailing.contact with bounce counters and failure reason fields set from the Bento bounce data. This protects sender reputation in Odoo's mail delivery configuration and prevents re-sending to addresses known to be invalid. Bounce records are processed as a standalone phase before any email-sending configuration is activated in Odoo.

Bento automations are visual behavioral flows using Custom Event triggers, delay nodes, and action blocks. Odoo Automated Actions use ir.cron schedulers and server actions with a fundamentally different trigger model. We export automation definitions as structured JSON metadata (trigger type, conditions, delays, action nodes, and flow screenshots) in a migration brief. The brief serves as a rebuild specification; the customer's Odoo admin or a certified Odoo partner recreates the logic as Odoo Automated Actions or Studio workflows post-migration.

Bento's transactional email SDK configuration (API credentials, template IDs, sending domain settings, SMTP settings) is documented as a configuration export. We deliver a settings brief covering the sending domain, DKIM/SPF configuration values, and any domain verification records. The customer re-enters these in Odoo's Outgoing Mail Server settings or configures a third-party SMTP relay (SendGrid, Mailgun, Postmark) that Bento was previously handling.

Connected integrations (Shopify, WooCommerce, Zapier, Calendly, or other third-party connections in Bento) are documented as a configuration export listing active integrations, the data sync scope, and API credentials. We do not recreate integrations at the destination. The customer uses the integration documentation to re-establish connections in Odoo using Odoo's native app integrations or the relevant connector module from the Odoo Apps store.

Bento's analytics dashboards contain aggregate metrics (open rates, click rates, unsubscribe rates, revenue attribution) that are exportable as summary screenshots and CSV aggregates only. Record-level engagement history migrates via the Custom Event log. Aggregate reports are documented for manual reference and as a baseline for Odoo reporting setup. Odoo's native CRM reporting is rebuilt using the migrated contact and activity data post-migration.

Bento email template content exports as raw HTML. Design-time variables, conditional content blocks, and dynamic personalization tokens (such as Bento's {{contact.first_name}} syntax) are documented with their current values so the destination team maps them to Odoo's mail.template Jinja2-style syntax ({{object.name}}). We export the HTML body and subject line separately. Full template rebuild in Odoo Mail is a manual step using the HTML content and variable mapping document.

Bento does not have a native deal or opportunity object, so no pipeline data exists to migrate. This is a structural gap, not a mapping limitation. We flag this explicitly during discovery. Teams moving to Odoo CRM create their pipeline stages from scratch in Odoo Studio or via the CRM settings. Historical campaign performance data (open rates, click rates, revenue attribution if configured) can be used as reference data when defining the initial pipeline stage structure and probability weights.