Migrate from Oracle Eloqua to Odoo CRM

Eloqua Contacts map directly to Odoo CRM Contacts. All standard fields (FirstName, LastName, Email, Phone, Address) and custom fields migrate as direct field-to-field mappings. The Eloqua ContactType and marketability flags (opt-in, bounced, unsubscribed) map to Odoo's opt_in field and a custom marketing_status selection field. Import is sequenced after Companies because the Contact's CompanyId (many2one) reference must resolve at insert time. Odoo's XML-RPC API ingests contacts in batches of up to 100 per request with exponential backoff on rate-limit responses.

Eloqua Accounts map to Odoo Companies. The organization name, domain, industry, address fields, and custom fields migrate as direct mappings. Country and State fields in Odoo require ID references rather than string values; we resolve these via Odoo's res.country and res.country.state lookup tables during the transform phase. Company is created before Contact import so that the many2one relationship is satisfied at the moment of Contact insert.

Eloqua CDOs are customer-defined objects with independent schemas. Odoo has no native CDO equivalent, so we pre-create the destination schema using Odoo Studio custom fields on the Contact or Company object for simple CDOs, or Odoo Project Tasks with custom fields for multi-record CDOs that require a separate data table. We export the CDO schema (field names, data types, picklists) during discovery, create the Odoo custom field structure via the Settings interface, then import CDO records with lookup resolution to the parent Contact or Account. Each CDO migration is scoped independently because schema complexity varies significantly.

Eloqua Campaign metadata (name, status, start and end dates, campaign type, budget, targeting criteria) migrates as Opportunity records in Odoo CRM with a custom eloqua_campaign_id field for audit. The multi-step campaign canvas logic (wait steps, conditional branches, trigger-based actions) is tightly coupled to Eloqua's campaign engine and cannot be exported. We document the campaign structure in a written campaign map during discovery, including step order, branching logic, and trigger conditions, for the customer's admin to manually rebuild in Odoo Marketing Automation app or as a Project task checklist.

Eloqua Programs (orchestration containers within Campaigns) migrate as Odoo Project records with Program metadata preserved in custom fields. The Program's step sequence, engagement rules, and nurture logic do not export. We deliver a Program logic inventory document during discovery that lists every Program's name, objective, step count, and action types so the admin can rebuild as Odoo Marketing Automation rules or a manual Project task checklist.

Eloqua Segments define dynamic contact audiences based on filter criteria; Shared Lists are static contact collections. We export segment filter definitions and list membership counts. Dynamic segment filter logic cannot be reconstructed automatically in Odoo because Odoo's CRM has no native segmentation engine for dynamic audience building. We deliver a segmentation inventory document listing each segment's filter conditions and contact count for manual rebuild using Odoo CRM Groups or tag-based filtering. Shared list memberships are preserved by adding all contacts in a list to a corresponding Odoo CRM Group.

Eloqua Email assets export as HTML content, subject lines, sender and reply-to addresses, and basic configuration. We transfer the HTML body and metadata. Rendering-specific elements such as Eloqua's field merge tokens, dynamic content blocks, and images embedded in Eloqua's asset library require manual rebuild in Odoo's email template builder because the destination email engine uses different token syntax and image hosting. We preserve the HTML source and a list of dynamic elements that need manual recreation.

Eloqua form field configurations (field names, field types, required flags, submission handling rules) export from the Custom Object Record Services and form metadata. We deliver a form field inventory documenting field names, types, labels, and submission logic for manual rebuild in Odoo's Website Form builder or Survey app. The visual layout and design of forms do not migrate and require rebuilding in Odoo's drag-and-drop form editor.

Eloqua's weighted demographic and behavioral Lead Scoring models are stored in proprietary configuration that has no export mechanism. We document the current scoring model structure during discovery: scoring categories, weight percentages, demographic triggers, and behavioral thresholds. The customer's admin rebuilds the model in Odoo using a combination of custom fields, computed scores, and optional third-party scoring apps available on the Odoo Marketplace. We do not attempt to export or approximate the scoring values.

Eloqua tracks email engagement events (opens, clicks, bounces) as activity records linked to Contacts. We export these as Odoo CRM Note activities with the original event type, timestamp, and asset name preserved in custom fields. The engagement event type maps to a selection field (opened, clicked, bounced, unsubscribed) and the related email asset is referenced by name. Note body captures the event summary for the activity timeline.

Eloqua form submission events export as Odoo CRM Note activities. The note records the form name, submission date, fields submitted, and the associated Contact. We preserve the field-level submission data in the note body for rep context during the activity timeline review.

Eloqua page visit events (tracked web pages) export as Odoo CRM Note activities with the page URL, visit timestamp, and session duration preserved in custom fields. Odoo does not have native web tracking, so these migrate as historical activity records for reference rather than live tracking data. The customer's admin rebuilds web tracking using Odoo's Website analytics or a third-party integration if continued tracking is required.

Eloqua picklists (controlled vocabulary for custom fields) export as CSV including display names and stored values. We re-create them as Odoo selection fields or many2one relations to a dedicated res.config.data model depending on picklist size and usage frequency. Small picklists (under 20 values) become Odoo selection fields; large picklists with independent records become dedicated many2one targets so that new values can be added without a field migration.

Eloqua asset library images and attachments download via the Bulk API asset endpoints. We re-upload them to Odoo's Document Management module (ir.attachment) and link them to the corresponding Contact, Company, or Opportunity record via res_id and res_model. Externally hosted images referenced by URL remain accessible; images embedded directly in Eloqua's asset library are preserved as binary downloads and re-uploaded to Odoo Documents.