Migrate from Oracle Eloqua to Mailchimp

Eloqua Contacts map directly to Mailchimp Members within a designated Audience. The email address serves as the subscriber hash for Mailchimp's identity model. Standard Eloqua fields (FirstName, LastName, EmailAddress, Phone, JobTitle) map to Mailchimp merge fields (FNAME, LNAME, EMAIL, PHONE, COMPANY). Marketing opt-in status migrates to the Member's Status field (subscribed, unsubscribed, pending, cleaned) and a GDPR_CONSENT merge field we create to preserve Eloqua's consent date and source. All imported contacts default to subscribed unless their Eloqua status is suppressed or non-marketable.

Eloqua Accounts map to a COMPANY merge field on the Mailchimp Member record. If the customer requires Account-level grouping in Mailchimp, we create tags using the Account name (for example, tag 'Lexia Learning' on all Members from that Account) or use Mailchimp's Groups feature under an Account Interests section. The mapping type is configuration because the customer chooses between merge field storage (simpler) and tag-based grouping (more queryable) during scoping.

Eloqua Shared Lists (static contact collections) map to Mailchimp Tags applied at the Member level. Each Shared List name becomes a tag name; Members in the list receive the corresponding tag. This preserves list membership for segmentation purposes. Dynamic Eloqua Segments (filter-based audiences) map to Mailchimp Segments, which are rebuilt as Mailchimp segment rules because dynamic filter logic does not export from Eloqua. We document every segment's filter criteria for manual reconstruction.

Eloqua Segments are defined by filter rules (field criteria, activity conditions, date ranges) that have no export mechanism. We extract the complete segment definition from Eloqua's UI during discovery, document it in structured rule format, and hand it to the customer for reconstruction in Mailchimp's Segments builder. Mailchimp Segments support field-based filtering and activity triggers but use different syntax and operators. This is a manual rebuild step, not an automated migration.

Eloqua Campaigns (orchestration containers with multi-step logic) do not migrate as code because Mailchimp's campaign model does not support the same multi-step canvas with conditional branching, wait steps, and CRM triggers. We export Eloqua campaign metadata (name, description, targeting criteria, step count, email assets used) as a campaign inventory document. The customer uses this to rebuild campaigns in Mailchimp's Customer Journey builder, which supports trigger-based entry and basic if-then branching but not the same complexity depth.

Eloqua Email Assets (HTML content, subject lines, sender addresses, from names) export as raw HTML files via the Bulk API asset export. We map subject line to Mailchimp Subject Line, from name and from email to Mailchimp From Name and From Email, and upload the HTML body as a Custom Email Template. Design rendering depends on Mailchimp's template compatibility with the source HTML; complex Eloqua email components (dynamic content blocks, field merge tokens, conditional content) may require simplification during the rebuild. We preserve the HTML source so the customer's designer can adapt it to Mailchimp's template structure.

Eloqua activity records (email opens, clicks, form submissions, page visits) linked to Contacts export as activity history. We map engagement data to Mailchimp's open and click tracking logs, which Mailchimp records natively for each Member. Historical activity data that predates the migration cannot be retroactively imported into Mailchimp's activity timeline. We preserve the historical engagement data in a JSON archive file for the customer's reference and reporting continuity. Member-level engagement scores from Eloqua are not transferred because Mailchimp does not have a native scoring model.

Eloqua CDOs are customer-defined objects with arbitrary field schemas that do not have a direct Mailchimp equivalent. We export CDO records via the Bulk API and map them to Member-level merge fields in Mailchimp. Each CDO becomes a separate merge field (with the CDO name prefixed, for example CDO_ContractValue) added to the Mailchimp Audience. For CDOs with many fields, we coordinate with the customer to identify the top-priority fields to migrate as merge fields and archive the remainder in a structured JSON export. CDO-to-Member lookup relationships (which CDO records reference which Contact) do not map into Mailchimp because Mailchimp has no relational object model; we document these relationships for the customer's admin to handle via external data storage if needed.

Eloqua Picklists define controlled vocabulary for custom fields. We export picklist definitions (display name and stored value pairs) as CSV and recreate them as Mailchimp merge field option values for dropdown, radio, or checkbox merge field types. This preserves data consistency for fields like Industry, Country, or Lead Source that use fixed vocabularies rather than free-text entry.