A Pardot to Marketo migration gets harder the moment there is more than one Pardot instance to move. Consolidating several 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 our consultants 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.
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 something honest 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. Done properly, 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 genuinely 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 behaviour changes too. Marketo dedupes on email address within a partition, not across them, so the same person can exist once in each — often what you want, since the same buyer might be a customer of one business and a prospect of another. It also means your person count is not your count of unique humans, and someone in finance will ask about that at renewal.
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 a job nobody volunteers for. 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.
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, and there is no honest way around that.
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, if tedious. 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.
An opinion you are welcome to argue with: 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 quietly 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 — the businesses are genuinely different — but you can standardise the shape: same field names, same threshold structure, different values per org.
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.
- 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.
- 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.
- Every asset a live program references, individually. If it can send, it gets read.
- 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 dull work that 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?
It depends far more on the number of instances and the Salesforce arrangement than on asset volume. 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.