Migrate from Oracle Eloqua to Microsoft Dynamics 365 Sales

Eloqua Contacts map to Microsoft Dynamics 365 Sales in a two-stage split. Unqualified prospects (no assigned sales rep, early engagement stage) map to Salesforce-style Lead records. Contacts with assigned sales ownership or Account association map to Contact records under an Account. We compute the split using Eloqua's contactScore, isBounceCount, and segment membership as proxies for qualification status. The original Eloqua contact ID, subscription status, and marketing consent flags migrate to Dataverse contact fields and contact-point consent records.

Eloqua Accounts map directly to Microsoft Dynamics 365 Sales Account. The Account Name, Website, Industry, Number of Employees, and Annual Revenue fields map from Eloqua Account standard fields. We preserve the Account ID as a custom field for reference back to the source system. Account-to-Contact associations migrate via the Dataverse Contact parentCustomerId lookup.

Eloqua CDOs with customer-defined schemas map to Dataverse custom tables. Each CDO's fields (text, number, date, picklist, boolean, lookup) map to the equivalent Dataverse column type. CDO-to-Contact relationship fields map to Dataverse lookup columns on the custom table pointing to Contact. We pre-create the Dataverse schema (tables, columns, relationships, picklist values) in a Sandbox environment before migration so that lookups are satisfied at insert time. CDO record volumes often require Bulk API chunking due to Dataverse batch limits of 2,000 records per request.

Eloqua Campaign metadata (name, type, status, start/end dates, budget, targeting criteria) migrates as Microsoft Dynamics 365 Sales Campaign records. Campaign step logic, conditional branches, wait steps, and trigger configurations cannot migrate as automation code and are documented as written artifacts. The customer admin rebuilds campaign orchestration in Microsoft Dynamics 365 Sales using Sales Campaign member distribution and manual list loading, or via Power Automate flows for more complex logic.

Eloqua Segments (dynamic filter-based audiences) and Shared Lists (static contact collections) migrate as Microsoft Dynamics 365 Sales Marketing Lists. Dynamic segment filter logic cannot be reproduced automatically; we export the filter criteria and deliver a written reconstruction guide mapping Eloqua operators to Dynamics 365 filter equivalents. Shared List memberships migrate as Marketing List member records linked to Contact or Lead.

Eloqua's weighted demographic and behavioral Lead Scoring models are stored in proprietary configuration with no export mechanism. We capture the current scoring model structure (score categories, weight percentages, threshold values, and the field-to-score mapping) as a written specification document. The customer's admin rebuilds scoring using Power Apps canvas components, Power Automate flows, or a third-party scoring solution like InsideView or Clearbit. Scoring results do not migrate; scoring history is not portable.

Eloqua engagement events (email opens, clicks, form submissions, page visits, unsubscribes, bounces) map to Dataverse custom activity records or the standard Email Engagement table. Each engagement event links to the Contact record via the Dataverse regardingObjectId lookup. We export engagement history via Eloqua Bulk API, transform timestamps and event types to Dataverse column schemas, and insert via Dataverse Web API with batch sizes of 2,000 records per request. Page visit duration and referrer URL data, where present, migrate as custom columns.

Eloqua email assets (HTML content, subject lines, from-name, from-address, reply-to) migrate as Dynamics 365 Email Templates stored in Dataverse. We export email HTML and metadata via the Eloqua Asset API and import as EmailTemplate records in Dynamics. Design rendering depends on the destination email client; inline CSS and images embedded via external URLs are preserved as-is. Customers who use Dynamics 365 Customer Insights - Journeys for email sending will need to reconfigure sender profiles and deliverability settings.

Eloqua form field configurations (field names, types, required flags, validation rules, thank-you message content) migrate as written specifications. The visual form builder layout cannot be transferred. We deliver a form field inventory document that the customer's admin uses to rebuild forms in Dynamics 365 Marketing (if licensed), Power Apps portals, or a third-party form tool. Form submission history migrates as Contact or Lead records with submission metadata.

Eloqua picklists (controlled vocabulary fields) export as CSV including display labels and stored values. We create corresponding Dataverse Option Sets in the destination schema before contact and CDO migration begins. Picklist value changes since the last full export require delta updates during migration.