Moving from Oracle Eloqua to Iterable isn’t a typical marketing automation migration. There are enough similarities between the two platforms that the move can look straightforward at first. Both manage customer data. Both build audiences. Both orchestrate campaigns. Both personalize content. Both send email. Both connect to the rest of your marketing technology stack. Look a little closer, though, and the differences start to matter a lot more.
Eloqua grew up as a B2B marketing automation platform. Most mature Eloqua environments are built around contacts, accounts, lead management, CRM sync, forms, landing pages, Campaign Canvas, Program Canvas, Custom Data Objects, lead scoring, and email. Over years of use, Eloqua often ends up responsible for far more than sending marketing messages. It becomes part campaign engine, part integration layer, part data processing platform, and part lead management system.
Iterable starts from a different place. Its architecture centers on users and the things those users do. User profiles, custom events, purchases, behavioral data, segmentation, campaigns, and Journeys work together to decide how and when someone should be engaged. Email is an important part of that model, but so are SMS, RCS, mobile push, in-app messages, web push, WhatsApp, and embedded experiences.
That creates both an opportunity and a challenge. The challenge is that some of what your team has spent years doing in Eloqua won’t translate neatly into Iterable. The opportunity is that it may not need to.
An Eloqua-to-Iterable migration is a chance to decide what your future marketing architecture should look like: which jobs belong in Iterable, which should move somewhere else, and which customer experiences you can finally build that were hard to pull off in Eloqua. So, where do you start?
What’s Similar Between Eloqua and Iterable?
Let’s start with some good news. Your Eloqua marketers aren’t walking into a completely unfamiliar world. The basic jobs they do today still exist in Iterable.
You still need audiences. You still need campaigns. You still need customer data, personalization, testing, reporting, consent management, integrations, templates, and automation. What changes is how those jobs get done.
What You Do in Eloqua |
How You May Approach It in Iterable |
What to Think About |
|---|---|---|
| Maintain contact records and fields | User profiles and profile fields | Decide which profile data Iterable actually needs |
| Sync with Salesforce | Native Salesforce integration (Integrations Hub) | Data comes in on a schedule. Plan the write-back separately |
| Build segments and shared filters | Segmentation, dynamic and static lists | Add event and Catalog criteria to your audiences |
| Build Campaign Canvas programs | Journeys | Redesign around entry signals, behaviors, goals, and exits |
| Personalize email content | Handlebars, profile and event data, Catalogs, data feeds | Rethink where personalization data lives |
| Manage Email Groups | Message channels, message types, subscription lists | Redesign the preference model instead of copying it |
| Track campaign engagement | System events, Campaign Analytics, Snowflake data sharing | Decide what engagement data has to flow downstream |
| Trigger external processes | Journey webhooks and APIs | Reassess which system should own each process |
| Import and export marketing data | APIs, Smart Ingest, and Integrations Hub | Build data movement around the future architecture |
| Run A/B tests | Iterable Experiments | Test more than subject lines |
That familiarity matters. Your marketers don’t need to relearn the fundamentals of digital marketing. They need to learn a new way of applying them.
Take an Eloqua nurture campaign. A prospect might enter a Campaign Canvas because they were added to a segment. The campaign sends an email, waits several days, checks whether the person clicked, sends another email, waits again, checks a field or activity, and eventually routes the prospect somewhere else.
You could rebuild something very similar as an Iterable Journey, but that shouldn’t automatically be the goal. The better question is whether the Journey can react to what the customer actually does between those messages. Did they come back to the website? Request pricing? Register for an event? Start a trial? Buy something? Update their preferences? Hit a lifecycle milestone? That’s where the migration starts getting interesting.
What Will Be New in Iterable?
For most Eloqua teams, the biggest change won’t be a particular Iterable feature. It’ll be how the team thinks about customer engagement. Eloqua programs usually begin with an audience: who qualifies for this campaign? Iterable gives you more reason to begin with a signal: what just happened, and what should we do about it?
Custom events capture important customer actions and can drive segmentation, personalization, Journey entry, decisioning, and conversion measurement. Instead of storing every interaction as a field or CDO record that some other process evaluates later, an event can become an immediate part of the customer’s experience.
Say someone requests a product demo. A demo_requested event can carry what was requested, where the request came from, the customer’s area of interest, and other useful context. That event can drop the customer into a Journey right away, and the Journey can use profile and behavioral data to decide what happens next. That approach makes several Iterable capabilities especially important during a migration.
Behavioral Data Becomes a Bigger Part of Your Architecture
In a mature Eloqua instance, it’s common to find dozens or hundreds of contact fields used as flags, like these:
- Downloaded_Whitepaper = Yes
- Attended_Webinar = Yes
- Product_Interest = Product_A
Those fields usually exist because some campaign needed a value it could check later. Iterable gives you another option. Many of those behaviors can be events, with properties that carry the context around the action. So your migration should include a real discussion about what belongs on the user profile and what should be captured as behavior.
Journeys Can Become More Responsive
Iterable Journeys can use custom events as entry sources and make decisions based on what happens next. That opens the door to experiences that change as customer behavior changes, so a nurture doesn’t have to stay a fixed run of five emails over 30 days.
Someone who requests a demo can leave the educational track right away. A webinar attendee can move into a related follow-up. A new customer can exit acquisition messaging and start onboarding. The migration should focus less on reproducing Eloqua campaign diagrams and more on finding the signals that should change the customer experience.
Cross-Channel Becomes a Real Design Decision
Plenty of Eloqua environments stay heavily email-focused even when other channels exist elsewhere in the stack. Iterable changes that conversation. Email, SMS, RCS, mobile push, in-app, web push, WhatsApp, and Embedded Messaging can all be part of one coordinated Journey. Embedded Messaging can even place personalized content directly inside your website or app, based on real-time eligibility.
That means channel strategy belongs in the migration plan, not in a “phase two” conversation you’ll get to later. Ask where customers actually interact with you and which channels make sense at each point in the lifecycle.
Personalization Can Pull From More Places
Eloqua marketers are used to field merges, dynamic content, CDO data, and other forms of personalization. Iterable brings a different toolkit. Handlebars applies logic inside templates. Profile and event data shape content. Catalogs hold shared business data like products, locations, events, offers, or accounts, and you can now segment on Catalog data directly. Data feeds pull current values from outside services at send time, and Journey Live Data can fetch fresh data in the middle of a Journey to route someone or personalize the next message without storing it on the profile.
That changes the data design conversation. Instead of asking, “How do we get all of this into the contact record?” you can ask, “Where should this data live, and when does Iterable actually need it?”
Experimentation and Decisioning Can Become Part of Normal Campaign Design
Iterable Experiments support testing across sender details, subject lines, preheaders, send times, message content, and conversion outcomes. Iterable’s Nova Intelligence adds Send Time Decisioning, Channel Decisioning, and Frequency Decisioning, along with Predictive Audiences and Brand Affinity, depending on your plan and use case. (If you knew these as Send Time Optimization or Predictive Goals, Iterable renamed them in October 2026.) For teams coming from a rules-heavy Eloqua environment, that’s a chance to build learning and optimization into the operating model instead of relying only on fixed campaign logic.
What Might Be Missing?
This is where Eloqua expertise really matters. The mistake would be judging Iterable only by whether it has an equivalent button for everything you use in Eloqua. Some things shouldn’t have a direct equivalent.
Your CDO Architecture Will Need to Change
Custom Data Objects can get deeply embedded in an Eloqua implementation. Teams use them for event registrations, product ownership, opportunities, subscriptions, transactions, preferences, account relationships, service history, campaign responses, and dozens of other things. No single Iterable feature should replace all of those uses.
Some CDO records should become events. Some information belongs on user profiles. Some shared reference data may belong in a Catalog. Some data should stay in a CRM, CDP, data warehouse, commerce platform, or another source system. And some old CDOs should simply go away.
So “map CDOs to Iterable” is the wrong task. Figure out what each CDO is doing, then decide the best home for it.
B2B Lead Management Needs an Owner
Eloqua often plays a big role in lead scoring, qualification, CRM campaign integration, lead routing, account-based processes, and the handoff to sales. Iterable is a customer engagement platform. It can take part in B2B journeys, and its native Salesforce integration now brings Contacts, Leads, Accounts, Opportunities, and custom objects into Iterable on a schedule. Today that sync runs one way, into Iterable. Iterable has announced that engagement data will flow back to Salesforce, and more features will arrive with future integration updates.
Either way, you still need to decide where each B2B operational job lives. Maybe Salesforce owns lead status and routing. Maybe a CDP or warehouse calculates qualification and propensity scores. Maybe an outside scoring model writes a score to the profile, and Iterable uses it for segmentation and Journey decisions. What matters is that each of these jobs has an owner before Eloqua is turned off.
Program Canvas May Be Hiding More Than Marketing Programs
This one is worth digging into. Program Canvas often handles operational work marketers barely notice anymore: normalization, routing, CRM updates, data cleansing, scheduled exports, CDO processing, field updates, and integration workflows.
Those processes shouldn’t automatically become Iterable Journeys. Some will become API integrations. Others will move to middleware, CRM automation, your cloud data platform, or somewhere else. That’s why the migration inventory has to uncover processes, and assets are only half the picture.
Forms and Landing Pages Need a New Strategy
If you’ve relied heavily on Eloqua-hosted forms and landing pages, treat this as its own workstream. Don’t assume those assets simply move into Iterable. Decide what your web experience should be going forward.
That might mean your CMS for landing pages, your website or app for forms, or a dedicated form or conversion tool. Submissions can then update Iterable profiles, create events, or trigger Journeys through the right integration. For some teams, taking forms and landing pages out of the marketing automation platform actually simplifies the architecture.
Historical Data Needs a Home
Eloqua may hold years of contact activity, campaign membership, form submissions, email engagement, and CDO history. That doesn’t mean all of it belongs in Iterable.
History you need for analytics can live in a warehouse or archive. Data you need for future engagement can be turned into useful profile attributes, audience indicators, or recent behavioral events. Migration is a good time to separate the data you have from the data Iterable needs.
The Eloqua-to-Iterable Migration Playbook
With those differences in mind, the migration plan itself should look different from a traditional platform conversion. These 12 steps move you from understanding what Eloqua does today to running an Iterable program that keeps improving after go-live.
One Final Test: Would You Build It This Way Today?
One question is worth asking all the way through an Eloqua-to-Iterable migration: “If we were designing this process today, with no Eloqua environment, would we build it this way?” If the answer is no, the migration is your chance to change it.
You don’t need every old field. You don’t need every CDO. You don’t need every campaign or every Program Canvas. And you certainly don’t need to recreate 15 years of accumulated martech decisions just because they exist.
Keep the business requirements that still matter. Keep the customer data that has value. Keep the processes that genuinely work. Then design the rest for Iterable. That’s the difference between moving from Eloqua to Iterable and migrating well.
Relationship One’s Marketing Geeks know both sides of that move. We know the Eloqua environments teams have spent years building, including the Campaign Canvases, CDOs, integrations, CRM processes, AppCloud apps, and the occasional surprisingly important Program Canvas hiding behind the scenes. We also help teams design and implement Iterable around the way they want to engage customers next.
Our Eloqua-to-Iterable Migration Playbook lays out all 12 steps, with the checklists, comparison tables, and scorecard we use with clients. If you’re weighing the move, mapping the gaps, or ready to start, let’s talk. We’ll help you figure out what should move, what should change, what belongs somewhere else, and what you can finally leave behind.
Share This
About the Author: Relationship One
