Moving to or from Pardot, now Marketing Cloud Account Engagement, is mostly a rebuild, not a lift-and-shift. Your data and history can transfer, but emails, forms, landing pages, and automations are largely recreated by hand in the destination. This guide covers what actually migrates, what gets rebuilt, the Salesforce-specific traps that sink do-it-yourself migrations, and a realistic timeline, whichever direction you are going.
Most migration pain comes from expecting a one-click transfer and discovering, mid-project, that assets do not carry over cleanly and that a single Salesforce rule can block the whole thing. The teams that migrate smoothly are the ones who plan for a rebuild from the start.
Which direction are you going, and why
Two honest reasons drive most moves, and being clear about yours shapes the whole project.
- Moving to Pardot usually means a team has standardized on Salesforce CRM and wants marketing automation living inside the same data model and security layer, rather than syncing across a boundary. Consolidating onto one vendor agreement is a common second reason.
- Moving off Pardot usually comes from wanting native landing pages, content, and analytics without bolting together separate tools, or from hitting Pardot’s automation limits at higher volume. Both are legitimate; a good migration plan is honest about them.
This guide leans toward moving into Pardot, since that is the more common path for teams already on Salesforce, but the mechanics and the traps are the same in either direction.
Before you touch anything
Three things belong at the very front of a Pardot migration, because getting them wrong causes the most rework.
- The one-connector rule. Salesforce allows only one active marketing automation connector at a time. You cannot run the old platform and Pardot connected to the same Salesforce org in parallel indefinitely. Plan the cutover deliberately, and disconnect the old connector when you are ready, not before you have validated the new one.
- Export everything first. Prospect data, custom field definitions, scoring and grading history, engagement history, email and template content, form and landing page HTML, and your automation logic. Assume you will need a clean copy of all of it outside the platform.
- Mind the sync catch-up window. After an outage or a long pause, the Salesforce connector does not always reconcile changes older than a set window, so a migration that drags on can quietly drop updates. Keep the sync healthy throughout and do not let the project stall mid-cutover.
Data model translation
The structures differ meaningfully between platforms, so this is rarely a straight field-to-field copy. Map custom fields to their new homes, decide what to do with scoring and grading history (Pardot scores and grades work differently from other tools’ models, so you often reset and rebuild rather than import a number that no longer means the same thing), and plan how engagement history will carry forward. Getting the data model right first is what keeps reporting trustworthy after the move.
What migrates, and what gets rebuilt
This is the expectation most teams get wrong. Data can move; assets are largely a rebuild.
- Rebuilt by hand: emails, email templates, forms, and landing pages. Images have to be re-uploaded to the destination and relinked. Budget real time for this; it is the bulk of the work.
- Re-created first: lists and segmentation need to exist in the destination before you can rebuild the automations that use them.
- Re-architected: nurtures and Engagement Studio programs, automation rules, and completion actions. You are translating logic, not copying it, which is a chance to retire the automations that no longer earn their keep.
The upside of a rebuild is that you do not carry years of accumulated cruft into the new instance. A migration is the best chance you will get to leave the dead programs behind.
A realistic timeline
A straightforward migration is commonly a six-week project at minimum, and complex instances take longer. The phases are predictable: audit and export, data model mapping, asset rebuild, automation re-architecture, a dual-run or overlap period where you validate the new instance against the old, and a planned cutover. The overlap period is where confidence is won or lost, so do not compress it to hit a date.
Validate before you call it done
After cutover, three checks matter most. Is the Salesforce sync clean, with no growing error queue and no prospects stuck between marketing and sales? Is scoring behaving the way you designed it, rather than firing false MQLs from imported history? And are the handoffs to sales working end to end? A migration is finished when those three are true, not when the last asset is rebuilt.
Where a consultant earns the fee, and where you can do it yourself
Plenty of a migration is straightforward rebuild work a capable in-house team can handle. Where outside help pays for itself is the parts that are easy to get quietly wrong: the data model mapping that decides whether your reporting survives, the scoring and grading design, the connector cutover, and the validation that catches a broken sync before it costs you a quarter of pipeline visibility. If you have the hands but not the Pardot depth, that is the split to plan around.
A straightforward migration is commonly at least six weeks, and complex instances take longer. The time goes into asset rebuild, data model mapping, automation re-architecture, and a validation or overlap period. Compressing the overlap to hit a date is the most common cause of post-migration problems.
Not connected to the same Salesforce org for long. Salesforce allows only one active marketing automation connector at a time, so you plan a deliberate cutover and disconnect the old connector once you have validated the new one, rather than running both indefinitely.
No. Emails, templates, forms, and landing pages are largely rebuilt by hand in the destination, and images have to be re-uploaded and relinked. Data and history can transfer, but assets are a rebuild. Budget most of the project time for this.
Usually not directly. Pardot’s scoring and grading work differently from other tools’ models, so an imported number often does not mean the same thing. Most teams reset and rebuild scoring during the migration, which is cleaner and avoids false MQLs from stale history.
Where to go next
More from our Pardot series: Pardot in 2026, Explained, Can an AI Agent Run Your Pardot?, and How to Vet a Pardot Partner.
If a migration is on your horizon, it helps to know the platform you are moving to or from. Our explainer, Pardot in 2026, covers what the product is today and where the roadmap stands, and our Pardot services page lays out how we help teams plan and run these moves.
Couch & Associates plans and executes Pardot migrations with the data model mapping, connector cutover, and validation that keep a move from costing you pipeline. If you are weighing one, talk to us before you set the go-live date.
