The recommendation typically arrives in two contexts: license renewal with an upgrade proposal, or a marketing stack audit that detects growth beyond Pardot's scope. In both cases, the Salesforce partner frames the change as a "migration" — and that is where the project begins accumulating surprises.
Pardot, rebranded as Marketing Cloud Account Engagement (MCAE) in 2022, and Marketing Cloud Engagement are not the same product at different scales. They are platforms with distinct architectures, different data models, and originally separate use cases.
What looks like a migration is almost always a reimplementation — with the budget and timeline of a new project.
Pardot and Marketing Cloud Engagement Start from Different Premises
MCAE was built for B2B marketing: leads connected to CRM opportunities, engagement-score-based nurture, forms feeding the commercial pipeline. The central data entity is the Lead — the same object as in Sales Cloud, with native synchronization and no additional configuration.
Marketing Cloud Engagement was built for B2C marketing at scale: batch email, multichannel journeys (email, SMS, push, ads), segmentation in Data Extensions, dynamic templates with AMPscript. The central data entity is not the Lead — it is the Subscriber, with an independent key and a CRM connection via Marketing Cloud Connect, configured separately.
This architectural difference cascades throughout the entire project:
Data model. MCAE uses Salesforce objects directly (Lead, Contact, Account, Opportunity). MCE uses Data Extensions — configurable relational tables with no native CRM link. Synchronization requires Marketing Cloud Connect, which must be configured, tested, and monitored as part of the project scope.
Template syntax. MCAE uses HML (Handlebars Merge Language). MCE uses AMPscript — a proprietary language with conditional logic, loops, and inline API calls. HML templates do not convert to AMPscript: they need to be rewritten.
Journey logic. MCAE's Engagement Studio is oriented toward CRM conditions: lead score, opportunity stage, object field values. MCE's Journey Builder is event-driven: data stream entry, external trigger, branching by Data Extension attribute. The business logic exists in both tools — but the available triggers and exit conditions are different enough to require redesigning programs, not converting them.
What Must Happen Before the Project Starts
Migration projects that hit surprises halfway through almost always skipped the diagnostic phase. Four inventories are mandatory before approving scope and timeline:
Active program inventory. How many Engagement Programs are running in MCAE? With how many steps? With how many leads inside? Each active program needs a Journey Builder equivalent — and the logic mapping is manual, not importable.
Template inventory. List actively used HML email templates (welcome, nurture, re-engagement). Abandoned templates do not need to migrate; frequently used ones need to be rewritten in AMPscript or converted to Content Builder drag-and-drop. Template count is the primary driver of timeline — not platform configuration.
Contact model mapping. In MCAE, the key follows the Salesforce model (Lead ID or Contact ID). In MCE, the key is the Subscriber Key — configurable as email, CRM ID, or a proprietary identifier. Defining this key before importing data avoids the most expensive problem: duplicate subscribers with fragmented history.
IP reputation history. For volumes above 100,000 emails per month, migration requires IP warming in MCE — a gradual process of 4 to 8 weeks that cannot be compressed without risk of landing on blacklists. Warming must appear in the project schedule with real buffer, not as a parallel track alongside go-live.
Pitfalls That Appear After Go-live
Even with a solid diagnostic, some difficulties surface in real use:
Marketing Cloud Connect is not plug-and-play. CRM integration requires configuring Synchronized Data Sources, field mapping, and latency testing. In rushed implementations, Connect works in sandbox and fails under real load — especially when there is a high volume of simultaneous Lead and Contact updates.
Permissions follow their own model. In MCAE, permissions follow Salesforce profiles. In MCE, the model is internal: Roles, Business Units, and Content Builder permissions must be configured separately. Teams with multiple brands or product lines need to redesign the access structure — not just replicate what existed in the CRM.
Reports do not migrate. MCAE campaign reports (open rate, click rate, generated pipeline) have no automatic equivalent in MCE. Intelligence Reports uses a different model, and the history of older campaigns rarely migrates faithfully to the new system.
License cost increases. MCE is an enterprise product priced differently from MCAE. Projects that treat migration as an "upgrade" frequently discover at the final contract that annual costs increased 40 to 100% — with a valid justification, but one that should have been in the business case from day one, not as a renewal surprise.
When Migration Does Not Pay Off
The same logic for evaluating when not to use Salesforce applies to the choice between MCAE and MCE: the cost of licensing and operations must justify the additional capability.
If the use case is primarily B2B — lead scoring, pipeline-based nurture, campaign reports tied to opportunities — MCAE is the more appropriate product. The native CRM integration, scoring logic, and Engagement Studio were built exactly for this case. Migrating to MCE in this scenario means paying more for a platform built for a different use case.
MCE makes sense when marketing operates with high volumes of transactional or multichannel communication — complex behavioral segmentation for B2C campaigns, or when Marketing Cloud needs to consume Data Cloud data for granular personalization at scale. In those scenarios, MCE's architecture delivers what MCAE cannot.
The qualifying question before any migration proposal: is the real use case B2C or multichannel at scale? If yes, the migration has solid technical grounds. If marketing remains pipeline-oriented B2B, the honest recommendation is to optimize MCAE rather than migrate.
The Real Scope of a Migration Project
For timeline reference: a migration with 10 to 20 active programs, 30 to 50 templates, and a mid-sized marketing team takes 12 to 20 weeks in well-managed projects. Not six — and not with the same team that handled the original Salesforce implementation.
Diagnosis occupies the first 4 weeks: program inventory, data model mapping, Subscriber Key decision, Data Extension design. Template rewriting and journey rebuilding occupy the following 6 to 10 weeks. IP warming and Marketing Cloud Connect testing run in parallel. A phased go-live — starting with the simplest programs — closes the project with lower risk.
Mapping what exists before starting to configure is the discipline that distinguishes successful CRM implementations from those that need to be redone two years later. In a marketing platform migration, the diagnostic is not overhead — it is the work that determines whether the project ends at go-live or at rework.