A Marketo to HubSpot migration is a rebuild of the execution layer for a team that has decided a more opinionated platform is worth the loss of granularity. People, field values and static lists move by export and field map. Scoring, lifecycle, routing and the CRM sync get rebuilt in HubSpot's own constructs, and Marketo's program, channel and token structure has no destination object at all.

Consultants at The InHouse Marketers have delivered this move. It sits under Marketo to HubSpot in our migration track record, next to the two pairs that run the other way: HubSpot to Marketo and HubSpot to Pardot. Platform work of this kind is part of our marketing automation practice.

Which Marketo objects have a HubSpot destination, and which have none?

Three columns, agreed in writing before the export and signed by whoever owns the reporting. The third column is the one that saves the project, because the objects Marketo reporting rests on are in it.

What a HubSpot import accepts: people and their field values, static list membership, and email and landing page copy as text, images and files. None of it is where the schedule goes.

What gets rebuilt in HubSpot's model: smart campaigns as workflows, engagement programs as a workflow plus a content sequence, segmentations as lists or smart content rules, scoring as a score property with its own attribute sets, lifecycle as HubSpot's lifecycle stage property, routing as workflow actions against HubSpot owners, and every form as a HubSpot form whose fields exist as properties first.

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. Export what the dashboards read before the Marketo subscription lapses.
  • Anonymous web history. The _mkto_trk cookie and HubSpot's hubspotutk cookie are unrelated, so a known person's pre-cutover browsing does not follow them. Their behaviour history starts the day the HubSpot tracking code goes live.
  • Program membership and channel statuses. Covered below, because it is the trap in this pair.
  • Velocity email scripts. Marketo email script tokens run server-side at send time, and anything built on them (a table of the person's own registrations, a block that varies by a field value in ways a token cannot express) has no HubSpot equivalent. Personalisation tokens and HubL modules cover the simpler cases. The rest is a rewrite or a deliberate cut.
  • Communication limits. Marketo caps how much mail a person can receive at the instance level. HubSpot has no single setting behind that, so the cap gets rebuilt as enrolment criteria, a suppression property, or an agreement about send calendars that someone has to police.

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

Because a smart campaign is smaller than a workflow. Marketo gives you a smart list, a flow and a schedule as three separable things, and teams use that separability: one campaign stamps a field, a second reads the field and sends, a third catches the people the second missed. A HubSpot workflow holds enrolment, branching, delay and action in one object. So the mapping runs the other way from what people expect. Several Marketo smart campaigns collapse into one HubSpot workflow, and the count of objects goes down while the logic inside each one goes up.

Two mechanics decide how much collapsing is safe. A Marketo smart campaign's schedule says whether each person can run through the flow once or every time, and a lot of inherited logic depends on which was set. HubSpot re-enrolment is a per-workflow setting available on some trigger types and not others, so a campaign that relied on running a person through repeatedly may need its trigger changed before the behaviour survives.

The other mechanic is that field-setting does not belong in a workflow. Marketo instances accumulate operational campaigns whose only job is to normalise a country value or stamp a source. In HubSpot some of that becomes a calculation property, some becomes a single workflow with branches, and some should stop existing. Decide which during discovery, from the field-use evidence in our audit checklist, and not while a delivery team is mid-build.

Anyone who hands a delivery team a spreadsheet mapping smart campaign to workflow has created a Marketo instance inside HubSpot. It will run. Nobody will be able to say why a person received two emails on a Tuesday.

How does a stored Marketo score become a recalculated HubSpot one?

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. Going into HubSpot the shape of the problem is specific. A Marketo score is a stored number that flow steps add to and subtract from as behaviour happens, including decay campaigns somebody wrote. HubSpot's score is recalculated from attribute sets you define. So the decay rules do not port as rules; they port as criteria, and some of them turn out to have been compensating for a bug nobody found.

Re-derive the model from conversion behaviour you can see, rebuild it with HubSpot's own constructs, and agree the thresholds with sales before anything routes on it. Expect the rebuilt score to land on different numbers. If MQL now means something different, sales should hear that in a meeting.

Lifecycle is the opposite problem. In Marketo nothing sets lifecycle unless somebody built it, which means the definitions are explicit and sitting in a smart campaign you can read. HubSpot's lifecycle stage is a built-in property that HubSpot itself will set in places, and it has its own rules about moving a contact backwards. Read the inherited Marketo definitions, decide which HubSpot stage each one maps to, then decide which automatic HubSpot behaviours you are keeping. Doing it in that order stops the platform overwriting a stage the business cares about without anyone noticing.

Why must every HubSpot form field exist as a property first?

Because a HubSpot form is assembled from properties, which makes the field map a prerequisite for the forms rather than a parallel task. No property, no field, no form, and that sequencing belongs in the plan with a date against it. The same rule catches the hidden values Marketo forms were populating from URL parameters, cookies and site JavaScript: each one needs a property before a HubSpot form can carry it. The inventory, the repointing register and the test submission read on the created record are set out in website forms during a migration.

One Marketo behaviour to decide about on purpose: progressive profiling and known-visitor pre-fill. HubSpot has its own version, driven by its own cookie, which starts empty. For the first weeks after cutover a returning person is a stranger to the form.

Who wins on each field once HubSpot connects to Salesforce?

If Salesforce is the CRM, this is the part to scope first, because the two platforms connect to it differently. Marketo's Salesforce sync is native and opinionated: one sync user, a field-level permission set somebody checked, its own schedule. HubSpot connects through an integration with an inclusion list deciding which records sync at all and a rule per property deciding which side wins. Those are different enough that the ownership question has to be answered again from scratch. For each field: which system is master, which direction it syncs, and what happens to the reports built on it. Write it down before the connector is switched on. Two systems updating Lead Source is not an argument to have retrospectively.

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 Marketo's unsubscribed field, any marketing suspended flag, the CRM opt-out field and whatever consent fields the forms were writing, read together and re-expressed as HubSpot subscription types with the evidence fields alongside. Suppression travels the same way and arrives faster: hard bounces, global unsubscribes and the manual do-not-contact entries have to be in HubSpot as one master list before the first send, because a clean new portal holding none of that history will mail every one of those people on day one.

Two HubSpot mechanics belong in the same conversation. HubSpot deduplicates contacts on email address, so two Marketo people sharing an address arrive as one contact and the merge rule has to be decided rather than discovered. And HubSpot's marketing contact status governs both who can be sent marketing email and what the subscription costs, so importing the whole Marketo database as marketing contacts is a commercial decision disguised as an import setting. Decide which populations are marketing contacts before the first load.

What is the trap in a Marketo to HubSpot migration?

Program membership. It is the one that does not show up in any other pair, because it is the object Marketo reporting is built on and HubSpot has nothing that holds it.

In Marketo a person carries an Acquisition Program, and sits in programs with a status drawn from that program's channel: invited, registered, attended, and a success flag set at channel level. Every number the marketing team trusts comes out of that structure. Program performance, channel comparison, cost per success, the funnel by first touch. HubSpot associates assets with a campaign and attributes contacts to campaigns through the assets they touched. There is no per-contact campaign status, no channel-level success definition, and no inherited history of who was invited to what.

So the status history either becomes properties and lists you design on purpose, or it stops existing at cutover. Both are defensible. What is not defensible is finding out in the first board deck after go-live. The practical sequence:

  • List the reports leadership reads, by name, with the Marketo object each one is built on.
  • For every report resting on program status or channel success, decide its HubSpot source before the export. A property per milestone, a static list per cohort, a warehouse table, or a note that the report is retired.
  • Carry the Acquisition Program value across as a plain field, whatever else you do. It is the only first-touch record you have, and it is cheap to keep.
  • Tell the people who read those reports which charts will look wrong and for how long, before the first one lands.

Marketo's token structure is the smaller half of the same trap. Program-level tokens let an asset read its own program's dates, links and copy, and they inherit on clone. HubSpot has no equivalent, so values that lived once in a token end up hard-coded into each asset unless somebody builds a convention. That is a maintenance cost rather than a reporting one, and it is the reason a migrated HubSpot portal feels heavier to run than the estimate said.

How do you know the rebuild is right?

By running both systems for a period and explaining every difference. New sends leave HubSpot; Marketo stays up and keeps taking form posts until a full campaign cycle has been through it. Then diff: submissions landing in both, field values matching, and both sides agreeing on who entered which program. You are not trying to make HubSpot match Marketo, because the logic was deliberately re-derived. You are trying to be able to explain each disagreement. An unexplained difference is a defect nobody has found yet. The six lenses we run this against are set out in how we run migrations.

Frequently asked questions

How long does a Marketo to HubSpot migration take?

What sets a migration timeline is the complexity of the operational layer, and not the volume of records. On this pair that means how many smart campaigns hold live operational logic, how much of the reporting rests on program status and channel success, and how quickly the business can decide which of those reports survives. People and field values export quickly. The decisions about what to drop are where the calendar goes, and they need someone senior in the room.

Do Marketo smart campaigns convert to HubSpot workflows automatically?

No. There is no export format HubSpot can consume, and the mapping is many-to-one: several smart campaigns usually become a single workflow, because HubSpot holds enrolment, branching, delay and action in one object where Marketo separates them. Treat the smart campaigns as documentation of intent and rebuild against HubSpot's model. A one-for-one rebuild produces a portal shaped like a Marketo instance that nobody can maintain.

Does activity history transfer from Marketo to HubSpot?

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 Marketo instance readable until they are rebuilt, and warn whoever owns the dashboards before the first report lands.

What happens to Marketo program statuses and channels in HubSpot?

They have no destination object. HubSpot associates assets with campaigns and attributes contacts through the assets they touch, with no per-contact campaign status and no channel-level success definition. Decide before the export which milestones become properties or static lists and which cohort history stops at cutover. Carry the Acquisition Program value across as a field, because it is the only first-touch record the old instance will give you.

Can a Marketo scoring model be rebuilt as-is in HubSpot?

No. 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. A Marketo score is a stored number that flow steps change as behaviour happens; HubSpot recalculates from attribute sets. Re-derive the intent, rebuild it with HubSpot's constructs, and agree the new thresholds with sales before anything routes on them.

What does the HubSpot marketing contact setting change about the import?

Which populations you can mail, and what the subscription costs. HubSpot distinguishes marketing contacts from the rest, and only marketing contacts can receive marketing email. Loading an entire Marketo database as marketing contacts turns an import setting into a commercial decision. Segment the export first: the people you intend to mail, the people you are keeping for sales context, and the people who should have been suppressed years ago.