Migrate from Oracle Eloqua to HubSpot

Eloqua contacts map directly to HubSpot contacts. Standard fields like email, phone, firstname, and lastname use HubSpot's built-in properties. The contact's primary company resolves to a HubSpot company association by domain match or by the primaryCompanyId value stored in Eloqua.

Eloqua accounts map to HubSpot companies. Company name becomes Company Name, domain maps to Website, industry maps to HubSpot's industry picklist, and employee count maps directly. Multi-site or subsidiary account structures in Eloqua need review — HubSpot does not have a native hierarchical company model, so parent-subsidiary relationships store in a custom property.

Eloqua CDOs that are flat (one field per contact) become HubSpot custom contact properties. Relational CDOs with multiple records per contact or cross-contact relationships require HubSpot custom objects (Enterprise tier) and a junction association — your admin must create the custom object schema in HubSpot before migration runs.

Eloqua campaigns map partially to HubSpot campaigns for email performance tracking. Campaign membership (which contacts were enrolled in which campaign) stores as HubSpot list memberships — one static list per Eloqua campaign. Campaign assets (email templates, landing pages, forms) do not migrate and must be rebuilt in HubSpot.

Eloqua programs track member enrollment and step progression. Program membership migrates as HubSpot list membership. Step-level progression data (which program step a contact was in) stores as a custom property on the contact record, preserving the enrollment context without recreating the program logic.

Eloqua email engagement events (opens, clicks, bounces, unsubscribes) map to HubSpot engagement activities on the contact timeline. Each engagement type becomes a separate activity record with original timestamps and campaign context preserved as activity metadata. This preserves the complete behavioral history of each contact so your team can see the full email engagement picture without relying on external reporting tools.

Eloqua form submission data stores as both a custom property on the contact (which form was submitted) and an activity event. If Eloqua captures form field values, each field becomes a custom property on the HubSpot contact. Multiple form submissions per contact accumulate as comma-separated or multi-value custom properties.

HubSpot tracks form submissions broadly. Landing page names from Eloqua migrate as a custom property (hs_landing_page_source) on the contact record, with submission timestamps preserved as an engagement activity. Full landing page assets must be recreated as HubSpot landing pages. This approach keeps the contact record clean while still preserving the historical context of which landing pages drove conversions in Eloqua.

Eloqua's lead scoring scale (which can vary per model and often extends beyond 100) rescale to HubSpot's 0–100 numeric property. We preserve the Eloqua score as a custom property with its original scale noted, and create a mapped hs_score property scaled to HubSpot's 0–100 range for use in HubSpot workflows.

Eloqua contact segments and shared lists migrate as HubSpot static lists. Active segment membership is preserved — contacts in an Eloqua group land in the corresponding HubSpot list. Dynamic segments (which re-evaluate based on criteria) require manual recreation as HubSpot smart lists.

HubSpot has no native field for the source system's internal ID. We create hs_eloqua_id as a custom string property on every contact record, storing the original Eloqua contact GUID for traceability, de-duplication across delta runs, and cross-referencing in audits. This GUID mapping ensures you can always trace any HubSpot contact back to its original Eloqua source record, even months or years after the migration.

Similar to the contact ID, the original Eloqua account GUID stores as hs_eloqua_account_id on HubSpot company records. This supports delta-run de-duplication and maintains the link between your historical Eloqua records and their new HubSpot counterparts. The company ID mapping also enables you to rebuild account-based reporting hierarchies and associate historical engagement data with the correct accounts after migration.

HubSpot overwrites Createdate when records are imported via API. The original Eloqua createdDate preserves as a custom datetime property (hs_original_createdate) on both contacts and companies, enabling reporting continuity and sorting by true record age in HubSpot's analytics. This ensures that contacts and companies appear in HubSpot reports with their original creation dates, maintaining historical accuracy for date-based filtering and cohort analysis.

Eloqua's email subscription flags (global opt-out, campaign-level unsubscribes) map to HubSpot's contact. Each Eloqua subscription list with its opt-in/opt-out status becomes a corresponding HubSpot subscription type, preserving the contact's preferences across all relevant email programs. This mapping ensures compliance with contact communication preferences and prevents accidental re-subscription during HubSpot onboarding.