A HubSpot to Marketo migration is the move teams make when scale or complexity has outgrown HubSpot. Workflows become smart campaigns, active lists become smart lists, and the program, channel, token and naming structure Marketo expects has to be designed before the first asset is built. HubSpot has no equivalent to inherit.

Consultants at The InHouse Marketers have delivered this move, and it sits under HubSpot to Marketo in our migration track record alongside the reverse direction, Marketo to HubSpot, and a CRM-side move, Salesforce to HubSpot. Marketo builds are part of our marketing automation practice.

What does the export carry into an empty Marketo instance?

Three columns, agreed before the export and signed by the marketing lead. Marketo supplies none of the structure the rebuilt objects land in, which is why the architecture decisions come before the build rather than during it.

What transfers with an export and a field map: person records, field values, static list membership, email and landing page copy, images and files. Marketo imports a CSV against its own field API names, so the map is written against API names and not the labels either platform shows a user.

What gets rebuilt in Marketo's model: workflows as smart campaigns, active lists as smart lists, lifecycle as an operational program somebody writes, scoring as explicit score fields with explicit decay, routing as flow steps and alerts, forms as Marketo forms or form handlers, and every email and landing page template as modules the editor can reorder. HubSpot drag-and-drop sections and HubL modules do not convert, so templates are a rewrite rather than a migration.

What cannot move at all:

  • Activity history. Activity history mostly stays behind: opens, clicks, form fills and page views remain in the old platform, so every report or scoring rule with a lookback window restarts at cutover. Pull the baseline numbers out of HubSpot before the portal is downgraded.
  • Anonymous web history. Anonymous web history restarts at cutover, because the two platforms' visitor cookies are unrelated and no connector reconciles them. A known person's behaviour history starts the day the Munchkin script is live on every page, including the pages nobody remembers owning.
  • Workflow enrolment history. HubSpot records which contacts have been enrolled in which workflow and uses it to decide re-enrolment. Marketo decides the same question from its own campaign membership, which starts empty, so a person who already received a HubSpot sequence can receive the rebuilt version unless you exclude them deliberately. That exclusion list has to come out of HubSpot before cutover.
  • HubSpot's automatic lifecycle behaviour. HubSpot sets lifecycle stage for you in places. Marketo sets nothing. The behaviour the team has stopped noticing is the behaviour that has to be specified and built.

Why don't HubSpot workflows become smart campaigns one for one?

Because one workflow is usually bigger than one smart campaign. A HubSpot workflow holds enrolment, branching, delay and action in a single object. Marketo splits those across a smart list, a flow and a schedule, and splits again between trigger campaigns that fire the instant something happens and batch campaigns that run to a timetable. So a workflow with three branches often lands as a program containing several smart campaigns, with the branch logic expressed as separate smart lists rather than as a tree.

Two Marketo mechanics change behaviour if they are set wrong, and neither has a HubSpot counterpart to copy from.

The first is the trigger-and-filter split inside a smart list. A migrated batch campaign with a trigger left in it will process a very large number of people the moment somebody runs an import. The second is the schedule setting that says whether each person can run through the flow once or every time. HubSpot re-enrolment is a per-workflow toggle; in Marketo it is a property of the campaign's schedule, and leaving the default in place is how a nurture sends a person the same email twice.

Treat the HubSpot workflows as a record of intent. Write down what each one is meant to achieve in one sentence, then build that sentence in Marketo's constructs. The inventory for this comes out of the field-use and program-use evidence in our audit checklist, run against the HubSpot portal before anything is created in Marketo.

What has to be built for scoring and lifecycle in Marketo?

Scoring models are not portable between platforms: a two-dimensional profile and engagement grid does not map onto a single score field, and behavioural decay is modelled differently in each platform. Out of HubSpot the specific gap is that HubSpot recalculates a score from attribute sets you define, while a Marketo score is a stored number that flow steps add to and subtract from. So decay stops being a setting and becomes a campaign somebody writes, schedules and owns. Nobody inherits that campaign. It has to appear in the build plan with an estimate against it.

Marketo also gives you as many score fields as you choose to build, which is an opportunity and a trap in one. Splitting behaviour from firmographic fit is usually the right call. Building nine score fields because the platform allows it leaves a model nobody can explain to sales. Re-derive the model from conversion behaviour you can see, rebuild it with Marketo's own constructs, and agree the thresholds with sales before anything routes on it.

Lifecycle is the bigger surprise. The HubSpot lifecycle stage property arrives in the export as a value, and it is tempting to map it to a Marketo field and call that done. The stage transitions, the timestamps reporting is built on, and the automatic setting HubSpot was doing are all absent. Lifecycle in Marketo is an operational program: stages as a field, transitions as trigger campaigns, a timestamp field per transition, and an exception path for records that arrive mid-funnel. Build it before the first asset lands, because the stamps have to be continuous across cutover for attribution to survive.

Do you rebuild as Marketo forms or as form handlers?

Decide form by form whether Marketo owns the page. A Marketo form where you control the landing page, a form handler where an existing site form has to keep posting from its current template. Each needs its field mapping written against Marketo API names, and each form handler needs its own post endpoint recorded. The hidden values HubSpot was populating from the embed code, query strings and site JavaScript get rebuilt against the new form and then verified on a created person record, which is the workstream set out in website forms during a migration.

Two Marketo form behaviours to settle early. Progressive profiling and pre-fill work from Marketo's own cookie, which starts empty, so returning visitors are strangers for the first weeks. And Marketo has no native per-topic subscription object: HubSpot subscription types become fields plus a preference centre landing page somebody designs, and the unsubscribe link in every template has to point at it rather than at the HubSpot page being retired.

What does the Marketo sync user decide about Salesforce?

If Salesforce is the CRM, the connection changes shape. HubSpot connects through an integration with an inclusion list and a sync rule per property. Marketo's Salesforce sync is native and opinionated: one sync user whose profile and field-level permissions fix which fields the integration can ever write, running on its own schedule. Widening that profile later means retesting every operational program that uses the fields, so it is an architecture decision taken in week one and not an admin task taken when somebody notices a write failing.

While both platforms are connected, name the master for each field in writing, and name the reports built on the fields that move before the connector is switched on. A field two systems both write is a field that reverts overnight.

Consent does not transfer with a database: an opted-in flag in one system is not evidence of consent in another unless the record of how and when it was captured moves with it. On this pair that means HubSpot subscription types, the legal basis fields if they were in use and the marketing contact status, read together and re-expressed as Marketo fields with the evidence alongside. Ask HubSpot in writing for the hard bounces, the global unsubscribes and the complaint flags early, because that history sits in the platform's own tables rather than in the person records you are exporting, and it belongs in one suppression list that is master in Marketo from the first send.

Then the Marketo default that catches teams arriving from a one-database platform. By default Marketo dedupes on email address across the whole instance, so when a person already in one acquired organisation's partition fills in another's form, the existing record is updated and no second record is created. Partition-level dedupe, where the same address can exist once per partition, has to be enabled by Marketo Support and can be set per input source. Decide which you want before the first import.

What is the trap in a HubSpot to Marketo migration?

There is nothing to inherit, and the structure cannot be retrofitted.

HubSpot hands you a working account on day one. Folders are optional, campaigns group assets without a convention, lifecycle moves on its own, and a score is maintained for you. Marketo hands you an empty instance and a set of decisions that every later object depends on:

  • Workspaces and person partitions. Which teams see which assets, which database each person lands in. Decide a partition boundary late and you are not making a configuration change, you are running a data migration inside your migration.
  • Channels and their progression statuses. A channel defines the statuses a program member can hold and which status counts as success. Change a channel's statuses after programs are using it and you have rewritten what success meant for every one of them, historical reporting included.
  • Program types and templates. Default, email, event and engagement programs behave differently. A clone-from-template convention is what keeps the hundredth program consistent with the first.
  • The token hierarchy. Tokens defined at folder and program level, inherited on clone, so a date or a link lives in one place. Skip this and the values get hard-coded into each asset, which is the cost nobody puts in the estimate.
  • A naming convention, written down. Marketo gives you folders and names as the only way to find anything. The discipline has to come from the team.
  • Sending subdomain, tracking domain and DKIM. Separate records doing separate jobs, requested in week one, because they sit in a ticket queue with a service level and no interest in your go-live date.

None of this is hard. All of it has to be decided before the build starts, by someone who will still be there in a year. The same architecture-first order shows up on every consolidation we have run, and the fullest account of it is the Pardot to Marketo consolidation, where a workspace and a person partition per acquired organisation set the pattern every later org inherited.

What does the parallel run have to prove?

That the architecture holds once real people are moving through it. Sends move to Marketo while HubSpot keeps taking form posts for a full campaign cycle, and two checks matter more on this pair than anywhere else: that nobody has run through the same program twice because a migrated batch campaign kept a trigger in its smart list, and that nothing has sent from both platforms on the same day. Exit criteria are agreed in advance, and meeting them is what releases the switch-off date already in the plan. The parallel run, the repointing register and the rehearsed rollback are set out in how we run migrations.

Frequently asked questions

How long does a HubSpot to Marketo migration take?

What sets a migration timeline is the complexity of the operational layer, and not the volume of records. On this pair the schedule is set by how much architecture has to be designed from nothing, how much logic is live in HubSpot workflows, and how long the sending subdomain, tracking domain and DKIM records take to come back from whoever owns DNS. A portal with many emails and little automation moves faster than a small portal running lifecycle, routing and scoring through undocumented workflows.

Do HubSpot workflows convert to Marketo smart campaigns automatically?

No. There is no export format Marketo can consume, and the mapping is one-to-many: a workflow holding enrolment, branching, delay and action in one object usually becomes a program containing several smart campaigns. Rebuild from intent. Copying the structure across leaves batch campaigns with triggers in their smart lists, which process the whole database the first time somebody runs an import.

Does activity history transfer from HubSpot to Marketo?

Activity history mostly stays behind: opens, clicks, form fills and page views remain in the old platform, so every report or scoring rule with a lookback window restarts at cutover. Person records, field values and static list membership can be recreated. Export the history your reports depend on to a warehouse or the CRM, keep the HubSpot portal readable until they are rebuilt, and warn whoever owns the dashboards before the first report lands.

What has to be designed in Marketo before the first program is built?

Workspaces and person partitions, the channels and the progression statuses that define success, program types and clone templates, the token hierarchy, a written naming convention, and the sync user's profile with its field-level permissions. Each one constrains every object created after it. A channel's statuses in particular cannot be changed later without rewriting what success meant for every program already using it.

Does Marketo deduplicate people across person partitions?

By default Marketo dedupes on email address across the whole instance, so when a person already in one acquired organisation's partition fills in another's form, the existing record is updated and no second record is created. Partition-level dedupe, where the same address can exist once per partition, has to be enabled by Marketo Support and can be set per input source, so form fills and list imports can follow different rules. Decide which you want before the first import.

How does HubSpot lead scoring get rebuilt in Marketo?

As explicit fields with explicit decay. HubSpot recalculates a score from attribute sets; a Marketo score is a stored number that flow steps change as behaviour happens, so decay becomes a campaign somebody writes, schedules and owns. Split behaviour from firmographic fit while you are at it, keep the number of score fields small enough to explain, and agree the new thresholds with sales before anything routes on them.