A marketing automation migration breaks at the logic layer, not the data layer. Contacts, assets and activity history move without much drama — the vendor will do most of that for you. What has to be rebuilt is everything that made those records mean something: scoring, lifecycle, operational programs, sync behaviour. Treat the project as a file transfer and you go dark mid-quarter.

Why does a marketing automation migration fail if the data arrives fine?

Because the data is inert. A lead record carrying a score of 87 means nothing in the new instance until something there can explain how 87 happened and what is supposed to happen next. Eloqua's shared filters, Pardot's automation rules, HubSpot's workflow re-enrolment and Marketo's trigger/filter split inside a smart list are not four dialects of one language. The execution models genuinely differ.

Batch versus trigger is the example people underestimate. Pardot automation rules historically evaluated on a recurring schedule and, unless you configured them otherwise, ran once per prospect. A Marketo smart campaign fires the instant its trigger fires, and will happily run somebody through the same flow again if you let it. Port the Pardot rule across as a like-for-like smart campaign and you have not migrated it. You have built something that behaves differently under load, on a Tuesday, when an import touches the whole database at once.

Between them, our consultants have delivered five of these: Eloqua to Marketo for an aviation agency; Pardot to Marketo, and later Marketo to Marketo, for a web-based solution provider absorbing the organisations it acquired; HubSpot to Pardot for a security services organisation; HubSpot to Odoo for an authenticator product company. The assets were the easy part every time.

What should you sequence first?

Start with the analysis, not the export. Someone has to sit with the source instance and write down what actually runs — which programs fire, which are dormant, which fire and achieve nothing. On the Pardot consolidation, the first real deliverable was not a migrated asset. It was a decision about which instance to migrate first.

That matters more than it sounds. Several acquired organisations, a Pardot instance each, all of it heading into one Marketo instance. Migrate the messiest one first and you spend the rest of the project reacting to it. Migrate the cleanest one first and you come out of it with a working reference architecture — naming conventions, channel setup, program templates, the operational layer — that every subsequent org gets folded into. We picked on which instance had the most reusable logic, not on which business unit shouted loudest. That is an argument you will have to win with a stakeholder at some point.

Rough order that has held up:

  • Instance architecture. Workspaces and person partitions per acquired organisation, a subdomain each, person partition rules. Get this wrong and it is not a fix-later problem, it is a rebuild.
  • The sync. Field mappings, the sync user's permissions, which object owns which field.
  • Operational programs — data normalisation, lifecycle, scoring, routing, unsubscribe handling. Plumbing. All of it should exist before a single campaign asset lands.
  • Templates, rebuilt in the destination's own module syntax. Not converted. Rebuilt.
  • Campaign assets and programs, in batches, reviewed after each batch.
  • Web data collection, forms and tracking.

Web collection deserves its own note. On the Eloqua to Marketo project the website's data-collection layer had to move as well, which meant rewriting the client-side capture as a front-end workstream in its own right — the detail is in the Eloqua to Marketo write-up. Nobody's original scope document mentioned that. They rarely do. Forms are the seam where the platform meets the actual website, and the seam is always more custom than the discovery call suggested.

What should you rebuild, and what should you abandon?

Abandon more than feels comfortable. This is the part people push back on, so, plainly: most legacy programs should not be migrated at all. A migration is the one moment where the political cost of deleting something is lower than the cost of keeping it, and you should spend that moment aggressively.

Our working rule, and you are welcome to a stricter one: if a program has not sent an email or written to a field in two quarters, it does not move. If nobody can name its owner, it does not move. If it exists because someone needed a one-off list once, it does not move. Archive the source instance, keep the export, and tell anyone who objects to go and find it in there. Almost nobody ever does.

What genuinely has to be rebuilt in the new platform's terms:

  • Scoring. Do not port the point values. Port the intent. Eloqua's profile-and-engagement grid does not collapse into a flat Marketo score field, and pretending otherwise gets you a model sales stops trusting without telling you. Re-derive it, then agree the thresholds with sales before you switch it on.
  • Lifecycle. Stage definitions, the transitions between them, and the timestamps that feed reporting. This is where a migration most often breaks attribution silently, because the stamps stop being continuous across the cutover.
  • Operational programs. Normalisation for country and state. Job titles, which are worse. Unsubscribe and preference handling, routing. On the HubSpot to Odoo migration a good deal of that logic ended up encoded in RegEx, because Odoo does not hand you a Marketo-style flow step and you build with what the platform gives you.
  • Anything containing a program token, which in Marketo means the program structure has to exist before the assets do.

What moves fairly mechanically: content assets, images, files, static lists, email copy. One caveat — an email template is content in the sense that a rendered PDF is a Word document. The output looks identical. The editable structure does not survive.

How much review does a migration actually need?

More than one pass, by someone who did not build the thing. On the Pardot to Marketo and Marketo to Marketo work, a defined share of the engagement went on reviewing the wider team's migrated output alongside the migration itself — checking the asset, the smart campaign logic, the tokens, the channel, the program status mapping, one program at a time.

It is tedious. There is no version of this that is not tedious. But review catches a class of error that testing misses: the program that works correctly and is wired to the wrong thing. A nurture stream with the right content, the right cadence and the wrong exit criteria will run for weeks looking healthy.

Worth putting on the checklist:

  • Program status to Salesforce campaign member status mapping. Wrong here and campaign attribution is quietly wrong for everything downstream.
  • Whether a smart campaign's smart list uses a trigger or a filter. A migrated batch program with a trigger left in it will process a very large number of people the moment someone runs an import.
  • Communication limits and operational flags on transactional sends.
  • Token inheritance in cloned program folders.
  • Whether the form is a native form or a form handler posting somewhere else entirely, and whether that endpoint still exists.

How long should the parallel run be, and what runs during it?

Long enough to cover one full cycle of every recurring process, which in most B2B organisations means at least one complete month-end and one full nurture cadence. Shorter than that and you find your gaps in production.

During the parallel run the old instance sends nothing and listens to everything. Turn off outbound at source — every email program, every alert — but leave tracking and sync alive where you safely can, so you keep a reference for what the source would have done. Then compare. A lead comes in through the new forms: does it land in the lifecycle stage the old logic would have given it? Does the score land in the same band? Does routing send it to the same owner?

Disagreements are the point. You are not trying to make the new instance match the old one, because you deliberately re-derived the logic and some of the old behaviour was wrong. You are trying to be able to explain every difference. An unexplained difference is a bug you have not found yet.

The one thing we would avoid: running both instances with live outbound sending, just in case. It gets proposed as a safety measure. It is a duplicate-send incident with a project plan attached.

Frequently asked questions

How long does a marketing automation migration take?

Far more depends on the complexity of the operational layer than on record volume. An instance with a handful of programs and a clean Salesforce sync moves quickly. One with heavily customised scoring, several business units and a bespoke web data-collection layer takes considerably longer, because that logic has to be re-derived rather than exported. The Eloqua to Marketo project described above ran September into October 2019, including the website migration and the webinar programs.

Can you migrate scoring models directly between platforms?

No, and trying is a reliable way to end up with a scoring model the sales team stops trusting. Platforms model scoring differently: a two-dimensional profile and engagement grid does not map onto a single score field, and behavioural decay works differently everywhere. Re-derive the intent behind each rule, rebuild it natively, then validate the output against records you already know well before anyone routes on it.

What happens to activity history during a migration?

Some of it moves, most does not, and you should plan for that early. Activity history in the destination usually starts at cutover, so any report or scoring rule that looks further back will behave oddly at first. Either export the historical activity to a warehouse for reporting, or accept the discontinuity and tell the reporting stakeholders yourself, before they notice it and tell you.

Do we need separate workspaces for each acquired business unit?

If the units have genuinely separate teams, separate domains and separate lead ownership, yes. On both the Pardot to Marketo consolidation and the Marketo to Marketo merge, each acquired organisation got its own workspace and person partition, plus its own subdomain. It costs setup time and it constrains cross-workspace sharing. The alternative — one shared space where anyone can accidentally email another unit's database — is worse.

What is the most commonly missed item in a migration plan?

The web layer. Forms, tracking scripts, the data-collection code on the site, and whatever custom JavaScript was written years ago to post into the old platform's form handler. It sits with the web team rather than with marketing operations, so it falls between the two during scoping. It is also the part most likely to need real development work rather than configuration.

Should we migrate to a platform nobody on the team knows?

Sometimes the commercial decision is already made and your job is to make it work. One migration took an authenticator product company from HubSpot to Odoo, which meant learning Odoo first and then training the team on it. That is a real cost and it belongs in the plan explicitly: budget for the learning curve and for building the enablement material, not only for the migration.