A Pardot to Marketo migration gets harder the moment there is more than one Pardot instance to move. Consolidating several Account Engagement (Pardot) instances into one Marketo instance is a design problem before it is a migration: a workspace and a person partition per acquired organisation, a subdomain each, a decision about which instance goes first, and a Salesforce connector that can only serve one arrangement at a time.

Acquisitions produce this shape. Each business that got bought arrives with its own database, its own sending domain, its own idea of what a qualified lead is. Most of what follows comes from a consolidation that consultants from The InHouse Marketers ran in 2020 for a web-based solution provider: several Pardot business units into one Marketo instance, for organisations that still operated as separate companies. It sits in our migration track record as the Pardot to Marketo row, and its Salesforce connector work falls under Salesforce consultancy.

Which Pardot instance should you migrate first?

Migrate the instance with the most complicated Salesforce relationship first, not the smallest one. The first instance you move sets the connector configuration, the sync user, the field mapping and the lead routing that every later instance has to fit inside. Build all of that around the easiest org and you will rebuild it when the difficult one turns up.

The instinct is to start with the simplest business unit and get a quick win on the board. That instinct is wrong whenever Salesforce is in the picture.

How we rank them, roughly by weight:

  • Whichever org owns the Salesforce instance the Marketo connector will point at. That one goes first, near enough regardless of size. Everything else is a guest in its CRM.
  • Volume of live automation, not asset count. A large email library with no logic behind it is a copying exercise. A smaller one with a scoring model wired into Salesforce workflow rules is a rebuild.
  • Sending reputation. Establish the org with the clean sending domain on its new subdomain first, so you have a known baseline to measure the rest against.
  • Who is available. Half the value of the first migration is the questions it forces the business to answer, and someone has to have the standing to answer them.

The counter-argument deserves a hearing: start small, learn the work, then take on the hard one. That holds where Salesforce was never connected to Pardot, or where each acquired org runs its own CRM. Where they share a Salesforce org, they share a constraint, and the constraint should lead.

How do workspaces and person partitions work in Marketo?

Workspaces and person partitions, one of each per acquired organisation. A workspace holds the assets and programs a team can see. A partition holds the person records. Set up this way, the marketing team at an acquired org logs in and sees only their own programs and their own people, while operations keeps the whole picture.

Partitions are not the security boundary people assume. A workspace can be granted access to more than one partition, and a smart list in that workspace will happily return people from both. If the requirement is that org A never emails a person owned by org B, you need the partition mapping right and a discipline about which workspaces see which partitions. Write it down before you build.

Deduplication needs a support ticket. By default Marketo dedupes on email address across the whole instance, so when a person already in org A's partition fills in org B's form, the org A record is updated and no org B record is created (Adobe Community: form fills across partitions). Partition-level dedupe has to be enabled by Marketo Support (Adobe: Understanding Workspaces and Person Partitions), and it can be set per input source, so form fills and list imports can follow different rules (Adobe: partitionName in custom dedupe rules). Decide which you want before the first import.

Assignment to a partition happens at record creation, so the person partition rules have to be right before anyone lands. Moving people between partitions afterwards is slow, manual rework. Cover all three creation paths: forms, list imports, and the Salesforce sync, which behaves differently from the other two.

Shared assets — templates, snippets, the global unsubscribe program — live in the default workspace with access granted outward, and you end up with a small shared core and a lot of org-specific children hanging off it.

All of that is configuration. Who is allowed to change it, whose consent applies to a person who exists in two partitions, and who owns the instance once the deal closes are separate questions, and they are the ones that stall projects. They are covered in consolidating marketing automation after an acquisition, and they are where our post-acquisition consolidation service starts.

Subdomains per organisation

Each acquired org gets its own tracking and landing page subdomain, mapped to its own branding domain in Marketo. go.orgname.com, not go.parentcompany.com/orgname. Reputation is tracked per domain, the acquired org's audience recognises its own brand, and if the parent later divests that business you hand back a clean domain instead of unpicking URLs out of years of email.

Set up the CNAMEs early. DNS changes at an acquired company go through whoever inherited the DNS when the founder left, and that person is not on your project plan.

What happens to the Salesforce connector during a Pardot to Marketo migration?

Marketo's Salesforce sync is a single connection with a single sync user, and only one system should be writing to a given object at a time. Pardot's connector and Marketo's running together against the same org produce field-level fights and duplicate activity logging. Plan the cutover per business unit, and the sync user's permissions before anything else.

  • The sync user needs field-level security on every field Marketo will read or write. By default it does not have it on custom fields created after the profile was made, which surfaces as a partial sync well into the project rather than an error on day one.
  • Pardot's connector user has been writing to fields Marketo now also wants. Decide which are retired, which are read once for historical value and abandoned, and which Marketo takes over. Retiring a field is a business decision dressed up as a technical one.
  • Campaign sync is the piece people forget. Marketo program membership maps to Salesforce campaign membership, so if the acquired org reports on Pardot-created campaigns, someone's dashboard breaks the day you switch. Tell them first.
  • Activity history Pardot wrote into Salesforce does not come across as Marketo activity. Marketo's log starts empty for those people, so plan reporting around the gap.

The clean cutover: pause the Pardot connector for that business unit, run a final sync, point Marketo's connector at the org, validate a sample of records by hand, then enable the sync. The messy version is where two business units share a Salesforce org and cannot cut over on the same day. You manage that with a field-level split and a lot of communication, and it is unpleasant for as long as it lasts.

What replaces Pardot scoring and grading in Marketo?

Marketo gives you one numeric score field out of the box and no grading concept at all. Pardot's model is two-dimensional — score for behaviour, grade for fit, rendered as A1 through F5 — so there is no direct equivalent. You rebuild it as two custom fields plus a scoring program, or you stop pretending the letter meant something.

Behavioural score is the easy half: a scoring program with smart campaigns per activity type maps to Pardot's rules closely enough that the conversion is mechanical and slow. Grading is the interesting half. Pardot's grade nudges a baseline letter up or down on field values; in Marketo you build a demographic score as a plain integer, driven by change-data-value triggers, and bucket it into an A-to-F field only if the business insists.

Our recommendation: do not rebuild the letter grade. It is a display format. It hides the numbers from the people making decisions, and sooner or later a sales team decides B2 means "call it" and C1 means "ignore" without telling anyone. Two integer fields and a written MQL definition are more useful and far easier to change.

The migration is also the only realistic moment to reconcile scoring across the acquired organisations. Several Pardot instances means several scoring models and several definitions of a marketing qualified lead. You will not merge them, because the businesses are different, but you can standardise the shape: same field names, same threshold structure, different values per org.

The same scoring and grading model read from the other direction, with a business agreeing grading criteria for the first time, is in the HubSpot to Pardot migration for a security services organisation.

How do you review migrated assets without checking every one?

Review by category and by risk, not asset by asset. Nobody is opening every migrated email individually. Check every template thoroughly, then a sample of assets per template, then everything carrying live logic — forms, anything with a token in a URL, anything in an active nurture.

  1. Templates first, in isolation. Rendering across the clients that matter to that org, the module structure, the editable regions, whether the token defaults are sane. A bad template multiplies.
  2. Forms and form handlers next. Pardot form handlers pointing at Pardot endpoints keep accepting submissions long after you think you have finished, and the data goes nowhere useful. Check the website source, not the Pardot asset list.
  3. Every asset a live program references, individually. If it can send, it gets read.
  4. A sample of everything else, weighted towards the org's most-used templates.

The work is spread across a team, and reviewing someone else's migrated assets is work people rush. The failure mode is not a broken email; those get caught. It is a correct-looking email with a hardcoded link to the old landing page domain, or a token resolving to the parent company's name inside an acquired org's workspace. Both look fine in preview. Both are wrong.

Give the review to someone who was not the migrator, and accept that a few assets will be found broken by a customer rather than by you. That is the trade against checking every asset individually, which nobody is funding.

Frequently asked questions

How long does a multi-instance Pardot to Marketo migration take?

What sets a migration timeline is the complexity of the operational layer, and not the volume of records. On a multi-instance consolidation the number of instances and the Salesforce arrangement set most of it. Each additional acquired organisation adds workspace and partition setup, DNS work, a scoring reconciliation and its own cutover window. The first instance is disproportionately slow, because it establishes the pattern the rest inherit.

Can you run Pardot and Marketo at the same time during the migration?

Yes, and on a multi-instance consolidation you have to, because the business units cut over on different dates. What you cannot safely do is have both connectors writing to the same Salesforce objects for the same records at once. Split by business unit, control which system owns which fields, and keep the overlap as short as the project allows.

Do you need a separate workspace for each acquired organisation?

Separate workspaces earn their keep when the acquired orgs have their own marketing teams and their own brand. One is fine when an acquisition has been fully absorbed and a single team runs everything. The middle case — separate brands, shared team — usually still argues for separate, because clutter in a shared workspace grows faster than anyone expects.

Is a Marketo to Marketo consolidation easier than Pardot to Marketo?

Easier in the assets, not in the design. Marketo to Marketo — which our consultants have also run for a web-based solution provider after a competitor acquisition — means templates and program structure port with much less rebuilding. The hard decisions are identical: partition design, a subdomain per org, which instance leads, the Salesforce connector.