Migrating from Pardot to Marketo: The Systems Decisions, Data Risks, and 90-Day Stabilization Plan

Platform migrations are one of those projects that consistently get underestimated — not because people don’t know they’re complex, but because the complexity is invisible until you’re inside it. The vendor checklist makes it look like a series of configuration steps. The reality is a sequence of consequential decisions, each of which carries data risk that won’t fully manifest until you’re in production.

This post is an anonymized account of a Pardot-to-Marketo migration we ran for a mid-market SaaS company: roughly 180,000 contacts, a seven-person marketing team, and an active pipeline that couldn’t be disrupted during the transition. Here’s the actual sequencing, the decision points that mattered, and the 90-day stabilization work that followed go-live.

What the vendor checklist doesn’t tell you

The official migration guidance from both Salesforce (Pardot) and Adobe (Marketo Engage) is oriented around technical completeness: have you exported all your assets? Have you recreated your forms? Have you mapped your custom fields? These are necessary questions, but they’re not the hard questions.

The hard questions are about data integrity, behavioral continuity, and organizational risk. What happens to leads currently in active nurture sequences when you cut over? How do you migrate engagement history in a way that preserves your scoring model’s validity? How do you run parallel systems during a transition without creating Salesforce sync conflicts? And how do you manage stakeholder expectations when the migration inevitably surfaces data quality issues that predate the project?

None of these questions appear on vendor checklists. All of them will determine whether your migration is a success or a prolonged crisis.

Phase 1: Discovery and data risk assessment (weeks 1-3)

The project started with a three-week discovery phase that had one primary goal: understand the current state of the Pardot instance well enough to know what we were actually migrating. Not what the team thought they had — what they actually had.

The discovery surfaced several significant issues. The engagement program structure in Pardot had been modified by multiple admins and had diverged from any documented design. Several active automation rules had conflicting logic that was being masked by the order of execution. The database had approximately 23% duplicate rate at the email address level — substantially higher than the team’s estimate of “a few percent.” And the Salesforce field mapping between Pardot and SFDC had never been formally documented, which meant there were custom fields syncing in undocumented ways.

Each of these issues required a decision before migration design could begin. We documented all of them in a risk register with priority, mitigation approach, and owner — and presented it to the client before a single migration task was scoped. The team needed to understand that they were migrating to Marketo and cleaning up their data state simultaneously, and that both projects had cost and timeline implications.

Phase 2: Marketo environment setup and baseline configuration (weeks 4-8)

Before any data or program migration began, we built the Marketo environment to a production-ready baseline. This included the workspace and partition structure, folder hierarchy and naming conventions, global token configuration, Salesforce sync setup with field mapping validation, email sending infrastructure (SPF, DKIM, dedicated IP warm-up plan), and the program template library for the five program types the client used regularly.

The Salesforce sync was the most consequential configuration decision in this phase. We chose to do a clean sync setup rather than inheriting the existing Pardot sync configuration — which meant carefully mapping every SFDC field to its correct Marketo counterpart, establishing the sync filter logic, and validating the initial sync with a subset of records before opening it to the full database.

The initial sync validation caught four field mapping errors that would have caused scoring data corruption if they’d gone undetected. This is why we always do subset sync validation before full database sync, regardless of how confident everyone is in the field mapping documentation.

Phase 3: Database migration and deduplication (weeks 6-10, overlapping)

Database migration ran in parallel with environment setup, beginning in week 6. The 23% duplicate rate meant that deduplication had to happen before the full database import into Marketo — otherwise we’d be importing 180,000 records that contained roughly 40,000 duplicate pairs, which would have created Salesforce sync conflicts immediately.

We ran deduplication in Salesforce rather than in Pardot, using the SFDC record as the master for merge decisions. This was deliberate: Salesforce was the system of record, and any merge that happened outside SFDC would create sync conflicts. The deduplication process took three weeks and required manual review of approximately 2,400 pairs where the automated merge logic couldn’t confidently determine the winner.

After deduplication, the final import into Marketo came in at 142,000 records — meaningfully lower than the pre-migration database size, which was the expected outcome but required advance stakeholder communication to avoid the perception that records had been lost.

Phase 4: Program migration and cutover (weeks 9-12)

Active programs were migrated last. The sequencing decision here was to migrate engagement programs (nurture) before operational programs (lead routing, alerting), and to run a two-week parallel period where Pardot remained active for in-flight nurture sequences while Marketo was being prepared to take over.

The cutover was executed over a weekend. We paused all active Pardot campaigns on Friday, completed the final record sync on Saturday morning, activated the Marketo programs and SFDC sync on Saturday afternoon, and ran validation checks through Sunday. Monday morning, the team was live on Marketo with all campaigns active and no send gaps visible to the database.

The 90-day stabilization period

Go-live is not the end of a migration project. It’s the beginning of the stabilization period — and in our experience, this is the phase that most migration projects underinvest in.

During the 90 days following cutover, we ran weekly sync health checks, monitored deliverability metrics closely against pre-migration baselines, tracked scoring model performance to detect any calibration drift from the database changes, resolved five SFDC sync errors that surfaced in the first 30 days, and conducted team training sessions in weeks 4, 8, and 12 post-cutover.

By day 90, the instance was operating within expected parameters on all key metrics. More importantly, the team had enough operational familiarity with Marketo that they could manage the instance independently — which was the actual success criterion, as opposed to the technical go-live date.