Migrate from Oracle Eloqua to Twenty CRM

Eloqua Contacts map directly to Twenty CRM Contacts. Standard fields (first name, last name, email address, phone, title, address) map to Twenty's typed Contact fields. Custom fields from Eloqua's contact field schema migrate to custom fields on the Twenty CRM Contact object. We resolve the EmailAddress field as the dedupe key to prevent duplicate Contacts on re-import. The original Eloqua Contact ID is preserved in a custom field for audit and cross-referencing purposes.

Eloqua Accounts map to Twenty CRM Companies. Account-level fields including industry, website, employee count, and revenue range map to the equivalent Company fields. The account-to-contact relationship is preserved by resolving the parent Company before Contact insert so that the Contact-Company association is established at migration time rather than patched afterward.

Eloqua engagement records (email opens, email clicks, form submissions, page visits) are exported as separate activity entries and mapped to Twenty CRM Activity records linked to the corresponding Contact. Each activity record captures the engagement type, timestamp, asset name, and URL. The activity ordering is preserved by setting the Activity date to the original Eloqua event timestamp.

Each CDO in Eloqua has its own schema with customer-defined fields. We export CDO records via Bulk API and map them to custom fields on the equivalent Twenty CRM object (Contact, Company, or Opportunity) where the field count is small (under 20 fields). For CDOs with complex schemas or more than 20 fields, we create extension tables in Twenty CRM and link them to the parent record via the original CDO's primary key. This requires pre-designing the extension schema before migration begins.

Eloqua Campaigns contain multi-step orchestration logic, wait steps, conditions, and trigger configurations that are tightly coupled to Eloqua's execution engine and cannot be exported as working records. We export campaign metadata (name, type, start/end dates, status, targeting criteria) and map campaign membership (which Contacts were added to which campaigns) as a tagged field on the Contact record. The customer's marketing ops team uses the campaign documentation to rebuild in their chosen automation tool.

Eloqua Segments define dynamic contact audiences based on filter criteria, and Shared Lists are static contact collections. We export the list membership (the actual Contacts in each segment or list) and tag each Contact with the segment or list names as a multi-value field in Twenty CRM. The dynamic filter logic that defines segment membership cannot be exported and must be reconstructed as a segment or filter in the destination platform.

Email HTML content, subject lines, sender addresses, and metadata are exported from Eloqua's asset library. The HTML is preserved as an attachment or note on the corresponding Activity record in Twenty CRM. Email rendering depends on the destination email tool's template engine and cannot be reconstructed as a working email template. The customer's admin uses the exported HTML as reference content for rebuilding in a new email platform.

Eloqua form field configurations (field names, field types, required flags, thank-you page settings) are exported as a JSON document and mapped to a Form documentation record in Twenty CRM. The visual layout and embedded JavaScript of Eloqua forms cannot be exported as working components. The customer's web team uses the field configuration documentation to rebuild forms in their web property or preferred form tool.

Eloqua's weighted demographic and behavioral lead scoring models are stored in proprietary configuration with no export mechanism. We document the current scoring model structure: which fields contribute, what weights are assigned, what thresholds trigger a score change, and how scores integrate with CRM opportunity data. The customer uses this documentation to implement equivalent scoring logic in their chosen sales or marketing intelligence tool.

Eloqua picklists define controlled vocabulary for custom fields. We export picklist definitions (display names and stored values) as a CSV and re-create them as picklist configurations in Twenty CRM where the platform supports picklist fields. This ensures that migrated custom field data uses consistent vocabulary rather than free-text values that would require cleanup after migration.