Short version: there is no forced deadline and no automated migration, which means the decision is yours to make well — or to postpone badly. Most established Engagement estates should not migrate this year. Most greenfield teams should not start on Engagement.
Key takeaways
- Marketing Cloud Next is not a new version of Engagement. It is a different foundation with a different data model, automation engine and personalisation syntax.
- Nothing lifts and shifts. AMPscript, SSJS, CloudPages and relational data extensions are rebuilt, not migrated.
- There is also no announced end-of-life for Engagement, so urgency should come from your roadmap, not from fear.
- Rebuild effort tracks custom-code density and integration count — not contact volume.
- Four viable paths, and “deliberate deferral with written triggers” is one of them.
The one architectural fact
Engagement grew up outside Salesforce core. Its own data model (data extensions), its own scripting languages, its own automation surface, and a connector shuttling data to CRM.
Marketing Cloud Next is built on Salesforce core, with Data 360 as the data layer and Flow as the automation engine. That single change explains every other difference.
| Marketing Cloud Engagement | Marketing Cloud Next | |
|---|---|---|
| Data | Data extensions, marketing-only | Data 360 unified profile, shared with CRM |
| Automation | Automation Studio, Journey Builder | Salesforce Flow, marketing flows |
| Personalisation | AMPscript, SSJS | Expression-based, Handlebars-style |
| Web pages | CloudPages | No equivalent — Experience Cloud or your own web platform |
| CRM link | Connector, with sync to manage | Native — no shuttle to break |
| AI | Einstein features | Agentforce, on the same data |
| Governance | Marketing-team owned | Platform-owned, org release process |
What does not come across
Be clear-eyed about this before any timeline conversation:
- AMPscript and server-side JavaScript. No compatibility layer. Every code block is re-expressed — usually by moving the logic up into Flow or into the data model, where it should have lived anyway.
- CloudPages. No equivalent at all. Preference centres, gated content and microsites need a new home — Experience Cloud, your own web platform, or a forms product.
- Relational data extensions. Re-modelled in Data 360.
- Journeys. Rebuilt as marketing flows. The design thinking transfers; the artefact does not.
- Content. No one-click content migration. This is often less painful than expected, because it is a chance to delete a decade of drift.
The dormancy dividend
Before sizing any migration, sort your journeys by entry volume over the last 90 days and read the bottom half. In most estates a large share are paused, superseded, or entered by nobody. Every one is scope you do not migrate. This single exercise usually removes more effort than any tooling decision.
Sizing it honestly
Effort correlates with complexity, not size. A retailer sending fifty million emails from twelve clean templated journeys is an easier migration than a mid-market B2B org with forty journeys held together by AMPscript and an undocumented CloudPage.
Score each from one to five:
- Code density — how much logic sits in AMPscript, SSJS and query activities rather than configuration
- Data model complexity — relational extensions and anything computed inside the platform
- Integration surface — how many live integrations, how many bespoke
- Journey criticality — how many would cause a revenue or compliance problem if paused for a week
- Organisational readiness — does a Data 360 model exist, and do marketing and platform teams already work together
Low across the board is a project. High is a multi-quarter programme. Mixed — the common case — usually points at hybrid.
The four paths
A — Greenfield
Who: new business units, brands or regions with little Engagement usage.
Why: you avoid building legacy you would only unwind later.
B — Hybrid coexistence
Who: a working estate plus genuine appetite for unified-data or agentic use cases.
Why: existing journeys keep running while you learn on something small and reversible.
Condition: you must write down which platform owns which contact, and enforce it with suppression. Two orchestration layers without an ownership rule will message the same person twice.
C — Phased replacement
Who: committed, large estate, multi-quarter runway.
Why: migrate by domain — one brand, region or lifecycle programme at a time.
Risk: phase fatigue. Sequence the visible wins early or you lose the sponsor.
D — Deliberate deferral
Who: heavy custom code, business-critical journeys, no Data 360 foundation, no use case Engagement cannot serve.
Why: because there is no deadline, and moving without a data foundation reproduces today’s problems on newer infrastructure.
Deferral only counts if you write the triggers
“Not yet” must come with the conditions that change the answer: our Data 360 model reaches a defined state, a named use case appears that Engagement cannot serve, our custom-code footprint drops below an agreed level, or the vendor announces something material. Review quarterly, in fifteen minutes. Without triggers, deferral is not a decision — it is the absence of one.
The readiness gate
One question outranks the rest: is there a Data 360 model a marketer can build a segment from without asking an engineer?
If yes, Marketing Cloud Next has something to stand on and the rest is delivery. If no, that is your project — and it is worth doing regardless of the migration decision, because a unified data foundation pays back in Engagement, in Sales Cloud, in Service and in reporting.
This is why “should we migrate?” is usually the wrong first question. The better one is “what would need to be true for a migration to go well?” — and the answer points at data, not journeys.
A structured way through this
The Migration Readiness Assessment produces the five inventories, a complexity score, a recommended path with the rejected options and why, a first-phase plan, the data-foundation gap sized as work, and written trigger conditions. Fixed scope, fixed price. It ends the speculation, whichever way it points.
The takeaway
The absence of a deadline is a gift, but only to organisations that use it to prepare rather than to postpone. Build the inventory, score the complexity, pick a path explicitly, and write down what would change your mind.