Migrate from Oracle Eloqua to Salesforce Sales Cloud

Eloqua Contacts with no sales engagement history (no opportunity association, no CRM sync activity) map to Salesforce Lead. Contacts with established buying intent signals or existing CRM records map to Salesforce Contact tied to an Account. We compute the split at migration time using Eloqua contact fields (ActivityType, OpportunityID, SFDCContactID) and apply a decision matrix agreed during scoping. The original contact record ID and all custom field values migrate to custom fields on both Lead and Contact for audit and future segmentation.

Eloqua Accounts map directly to Salesforce Account. The Account Name maps to Name, Domain maps to Website, and Industry maps to Industry (with picklist alignment). Account-to-Contact associations migrate as Contact records with AccountId resolved via the Account lookup. We deduplicate on Account Name and Domain during import to prevent duplicate Account creation.

Each Eloqua CDO has its own schema of standard and custom fields. We export CDO records via Bulk API and create equivalent Salesforce Custom Objects with __c API names matching the CDO identifiers. CDO fields map to custom fields on the destination object by type (text, number, date, picklist). Lookup fields from one CDO to another or from CDO to Contact/Account are preserved as external ID relationships resolved during the import phase. We design the destination schema in Sandbox before any CDO data loads.

Eloqua Campaigns (multi-step orchestration containers) migrate as Salesforce Campaign records holding campaign metadata (name, start/end dates, cost, status). The multi-step Program Canvas logic does not migrate because it is tightly coupled to Eloqua's campaign execution engine. We deliver a Program Canvas inventory document describing each campaign's steps, conditions, wait periods, and triggers for the customer's admin to rebuild in Salesforce Flow. Campaign membership (which contacts were in which campaigns) migrates as Campaign Member records with Member Status mapped from Eloqua response statuses (Sent, Opened, Clicked, Responded, Registered, Attended, No Show).

Eloqua Programs (reusable campaign building blocks) map to Salesforce Campaigns with a naming convention that distinguishes them from primary campaigns. Program Canvas dependencies and shared assets are documented in the automation inventory. Programs that contain contact segmentation rules generate corresponding Salesforce Campaigns with Segment-defined membership rather than program-based membership.

Eloqua Segments define dynamic contact audiences based on filter criteria. We export segment definitions (filter logic, field conditions, operator types) and generate corresponding Salesforce Campaigns whose membership reflects the segment at migration time. Dynamic segment logic must be rebuilt in Salesforce using filters, reports, or Flow; the segment definition document we deliver includes the equivalent Salesforce filter criteria for each segment.

Eloqua Shared Lists are static contact collections. Each Shared List becomes a Salesforce Campaign with membership built from the static contact list at migration time. List name becomes Campaign Name; list description maps to Campaign Description. Shared Lists do not maintain a live sync relationship in Salesforce; ongoing list maintenance requires manual campaign membership updates or a complementary marketing automation tool.

Eloqua Email Assets (HTML content, subject lines, sender addresses, reply-to addresses) migrate to Salesforce Email Templates. We export email body HTML and re-import as Salesforce HTML email templates. Design rendering depends on the destination email client's compatibility with the original HTML; we flag any email assets with inline CSS that may not render consistently. Subject line, sender name, and sender email migrate as template merge fields. Email assets used in active campaigns are flagged for priority migration.

Eloqua form field configurations (field names, field types, required flags, default values, thank-you page URLs) export as form metadata. We deliver a form specification document describing each Eloqua form's fields, routing logic, and webhook integrations for rebuild in Salesforce Web-to-Lead, Experience Cloud forms, or a third-party form tool. The visual layout and design of Eloqua forms do not migrate and require rebuild at the destination.

Eloqua tracks engagement events as activity records linked to Contacts (EmailOpen, EmailClick, FormSubmit, PageView, WebinarRegister, WebinarAttend). We export activity records via Bulk API and map them to Salesforce Task and Event records. Email-related activities (opens, clicks) become Task records with a custom activity type field; webinar and event activities become Event records. WhoId on each record points to the migrated Contact or Lead; ActivityDate preserves the original Eloqua timestamp. Large activity exports (over 100,000 records) are chunked into 10,000-record batches per Salesforce Bulk API limits with exponential backoff.

Eloqua picklists (controlled vocabulary for custom fields) export as CSV with display names and stored values. We create corresponding Salesforce global value sets or custom picklists in the destination org, preserving both the display label and API value. Picklist values are created in the destination org before any record imports that reference them to prevent validation rule failures on load.

Images and attachments stored in Eloqua's asset library export via the Bulk API asset download. We re-upload assets to the Salesforce Files library and link them to the relevant records via ContentDocumentLink. Images embedded via external URLs in email assets are preserved by maintaining the external URL reference; images hosted within Eloqua are downloaded and re-hosted. Asset library folder structure does not migrate and requires reorganization in Salesforce.

Eloqua's Lead Scoring models (weighted demographic scores, behavioral scores, and model thresholds) are stored in proprietary configuration with no export mechanism. We cannot migrate scoring models as code. During discovery, we document the current scoring model structure including score weights per demographic field, behavioral activity point values, model thresholds for grade assignment (A/B/C/D/F), and any scoring change triggers. This specification document is delivered to the customer's admin for rebuild using Salesforce Flow, Salesforce Connect, or an AppExchange scoring tool like Saleswings or Veloxy.