An Eloqua to Marketo migration is two projects sharing one name: moving assets and programs across, and moving the website's data collection across without losing a submission. The second is the one that gets under-scoped. Eloqua's Campaign Canvas and Marketo's Smart Campaign model do not map one to one, so budget for rebuilding logic rather than translating it.

What actually has to move?

Fields and picklist values move first, then forms and whatever code posts to them, then templates, then programs. On the migrations we've run, the inventory that matters is smaller than the one the client hands you. Most of the asset list is dormant. What matters is the short list of things actually holding the system together: the form handlers, the source-stamping logic, the unsubscribe path, the CRM field mappings.

What does not move is worth saying out loud in week one, because someone will assume otherwise in week three. Contact activity history stays in Eloqua. Email sends, form submits, page views, campaign membership — none of it lands in Marketo's activity log, and no connector fixes that. Export what reporting genuinely depends on, then treat the old instance as a read-only archive for as long as the contract runs. Anonymous web behaviour is worse. The Eloqua visitor cookie and Marketo's mkto_trk cookie are unrelated, so a known person's pre-cutover browsing does not follow them; their history starts the day Munchkin goes live.

Why is the website data-collection layer the hardest part of an Eloqua to Marketo migration?

Because the site never stops. Nobody signs off a weekend where the forms are down, and the enquiries that would have arrived during a gap are not recoverable — as far as the database is concerned they never happened. On an Eloqua to Marketo migration our consultants delivered for an aviation agency across September and October 2019, the marketing site was collecting into Eloqua through its own front-end layer and had to start collecting into Marketo instead. Tracking and form capture were rebuilt in AngularJS with Handlebars templates and plain JavaScript, version-controlled over GitHub, so the whole layer could be reviewed, staged and rolled back rather than hand-edited on a live server.

The shape of the work, if you are scoping something similar:

  • Every form's field set gets mapped to Marketo API names. Not display labels, and not the Eloqua field names — two fields called "Job Title" in the two systems will still fight you.
  • The hidden fields are where the pain is. UTM parameters, GCLID, referrer, internal source and sub-source values, consent flags, whatever else the site was stuffing into the Eloqua form post. Nothing looks broken while they are missing, which is exactly the problem.
  • Handlebars earned its place. Field markup defined once and compiled into every form, so a rename touched one template instead of every page carrying a form.
  • Munchkin goes on every page, including the ones nobody remembers owning.
  • associateLead and the mkt_tok handling on email links need testing on the pages that actually matter, which are the gated ones.
  • Angular's digest cycle and Marketo's Forms 2.0 script do not love each other. Loading a form off-screen and calling submit() with addHiddenFields() is the pattern that survived; embedding Marketo's own form markup inside an Angular view meant fighting the styling and the validation for no benefit.

We would rather have the site post to both systems for a short overlap — Eloqua still receiving while Marketo starts — than flip a hard switch on a Friday. Plenty of people will disagree with that. It creates duplicate records, it annoys whoever owns data hygiene, and it is unquestionably messier. It also means that when a field mapping is wrong you find out by comparing two sets of submissions, rather than by reading an apology email from the sales team. The mess is recoverable. A week of lost enquiries is not.

One more thing about the old system. The Eloqua form handler will keep accepting posts long after everyone has agreed it was decommissioned, which is either a useful safety net or an undocumented data collection point, depending on the day you look at it. Turn it off deliberately, on a date, with someone accountable for it.

Why don't Campaign Canvas and Smart Campaigns map one to one?

They model different things. A Canvas campaign is a flow: a person enters at a step and walks a path, with waits and decision splits drawn on a canvas. A Marketo program is a container, and the Smart Campaigns inside it are separate trigger or batch units, each with its own smart list and flow, none of which know about each other unless you make them. Nurture is the clearest break. Eloqua's canvas is a sequence; a Marketo Engagement Program is a cadence pushing streams of content at a person until they exhaust it. Those are not the same object with different buttons.

Projects go wrong when someone builds a mapping table that says Canvas step equals flow step, then hands it to a delivery team as a spec. What you get is a Marketo instance shaped like an Eloqua instance, full of wait steps standing in for cadence, with nobody able to answer why a person received two emails on a Tuesday. Rebuild the intent instead. Write down what the campaign is meant to do in one sentence, then build that in Marketo's model — triggers where behaviour drives it, batches where a schedule does, an engagement program where the point is a drip that eventually runs out.

What happens to email and landing page templates?

They get rebuilt. Eloqua's email HTML can be forced into Marketo by wrapping it in mktoModules and hoping — we have seen instances where someone did exactly that, and every subsequent edit went through a developer because the marketing team could not touch anything without breaking the layout. Build the templates properly: modules that can be added and reordered, mktoText and mktoImg variables exposed where an editor needs them, program-level tokens so dates and links are not hard-coded into every asset.

Landing pages are the same argument with more CSS. Guided templates, element names that mean something, and a form embed that does not need a developer for every new campaign. It is dull work and it takes longer than the estimate. It is also the difference between an instance a team can run and one they queue against.

Which operational programs go in first?

Data normalisation, before a single asset is imported. Country and state values, job title grouping, the company name cleanup nobody wants to own — build these as trigger campaigns firing on create and update, and let them run while the rest of the migration happens, so the database is already clean when the first real send goes out.

After that, in rough order: lead source and first-touch stamping, which Marketo does not do for you and which the Eloqua field probably had rules hanging off; lifecycle and status transitions; scoring, rebuilt rather than copied, because Eloqua's split between profile and engagement scoring does not translate; routing and alerting; the unsubscribe and preference path, including the CRM field that actually governs it; and error handling — a campaign that catches records with no email address or a failed sync, and tells someone.

What about integrations, webinars and nurture?

The CRM sync is the integration that will bite. Marketo's Salesforce sync is native and opinionated: it runs on its own schedule, writes activity back, and needs a dedicated sync user with field-level permissions someone has actually looked at. If Eloqua's integration is still writing to the same Salesforce records while Marketo starts, decide now which system wins on each field, and write it down. Two systems updating Lead Source is not a debate you want to have retrospectively.

Webinars need timing discipline. Do not cut over mid-cycle. Registrations for an event running after go-live will otherwise sit in the old instance, with confirmation and reminder emails scheduled from a platform you are switching off. Either finish the cycle in Eloqua, or move the whole thing — registration form, program statuses, reminders, follow-up — before registration opens. The aviation migration took the second route, and the major webinars moved as part of the cutover.

Nurture goes last, because the fields, the scoring and the templates all have to exist first. Build the engagement program, load the streams, set the cadence, then leave it paused until someone senior has walked through what a person actually receives, in order, from the moment they qualify.

Frequently asked questions

How long does an Eloqua to Marketo migration take?

It depends almost entirely on the website layer and the number of live programs. The aviation agency migration described here ran across September and October 2019 and covered asset migration, operational programs, integrations, the website data-collection rebuild, major webinars and nurture. A migration with a static site and few forms is considerably shorter. One with a single-page app collecting into Eloqua is not.

Can Eloqua campaigns be moved into Marketo automatically?

No. There is no export from Campaign Canvas that Marketo can read, and third-party tools claiming to translate campaign logic produce something you will rebuild anyway. Assets can be migrated with a mix of tooling and manual effort. Campaign logic has to be re-authored against Marketo's trigger, batch and engagement model. Treat the Eloqua canvases as documentation of intent, not as a build spec.

Does contact activity history transfer from Eloqua to Marketo?

Not in any usable form. Email sends, opens, clicks, form submissions and page views stay in Eloqua's activity log and cannot be written into Marketo's. Person records and field values migrate fine. Decide before cutover which historical data your reporting genuinely needs, export it to the warehouse or the CRM, and keep the Eloqua instance available read-only until that reporting cycle closes.

Do you need a developer for the migration?

If the website collects data, yes. Rebuilding tracking and form capture against Marketo means working in whatever framework the site runs on, mapping every field and hidden field, and testing submissions end to end before the old endpoint is retired. A marketing operations person can specify all of it. Someone still has to write the code and version it, and reviewing it in GitHub rather than editing live is not optional.

What gets missed most often?

Hidden fields, followed closely by the unsubscribe path. Hidden fields are missed because forms look correct in a browser while silently dropping source data, and nobody notices until attribution reporting is built on top of it. Unsubscribes are missed because the mapping between Marketo's Unsubscribed field, the CRM opt-out field and any consent fields is rarely documented anywhere before a migration forces the question.