Two facts shape every Marketing Cloud Next conversation, and they pull in opposite directions. There is no announced end-of-life forcing you off Marketing Cloud Engagement. And there is no automated migration path that lifts your journeys, content and AMPscript across.
Together they create a specific trap: because nothing is forcing the decision, teams defer it; because nothing automates it, the eventual project is larger than anyone budgeted. The way out is to separate the readiness assessment from the migration. The assessment is a few weeks of structured work. The migration is a programme. You should not commit to the second without having done the first.
Key takeaways
- Inventory before opinion. Most migration debates are conducted without anyone knowing what is actually running.
- Sizing is driven by custom code, integrations and journey count — not by contact volume.
- There are four viable paths, and “hybrid” is a legitimate destination rather than a fudge.
- The readiness gate is your data foundation. If Data 360 is not modelled, Marketing Cloud Next has nothing to stand on.
- Decide the trigger conditions now, even if the answer today is “not yet.” A documented “not yet” is a plan; an undocumented one is drift.
Part one: the inventory
Five lists. They can be built in two to three weeks by one person with the right access, and they change the conversation completely, because the argument stops being about strategy and starts being about a spreadsheet everyone can read.
| Inventory | What to capture | What it tells you |
|---|---|---|
| Journeys and automations | Name, owner, status, last modified, entry volume in the last 90 days, business criticality | How much is genuinely live. Expect a third to be dormant. |
| Custom code | Every AMPscript block, SSJS script, CloudPage, Query Activity and API-driven send | The single biggest driver of rebuild effort |
| Data model | Data extensions, relationships, update mechanisms, retention, which are actually queried | What has to be re-expressed in Data 360 |
| Integrations | Every inbound and outbound connection, its owner, its auth method, its failure behaviour | The hidden dependency list — usually longer than anyone expects |
| Content | Templates, reusable blocks, asset volume, brand variants, languages | Production rebuild effort, and the chance to delete a decade of drift |
The dormancy dividend
Sort the journey inventory by entry volume over the last 90 days and read the bottom half. In most estates a substantial share of journeys are paused, superseded or entered by nobody. Every one of those is scope you do not migrate. This single exercise routinely removes more effort than any tooling decision.
Part two: sizing honestly
Rebuild effort in Marketing Cloud Next correlates with complexity, not with size. A retailer sending fifty million emails a month from twelve clean, templated journeys is an easier migration than a mid-market B2B org with forty journeys held together by AMPscript and a CloudPage nobody documented.
Score each of these from one to five:
- Code density — how much logic lives in AMPscript, SSJS and query activities rather than in configuration.
- Data model complexity — relational data extensions, derived fields, and anything computed inside the platform rather than upstream.
- Integration surface — count of live integrations and how many are bespoke.
- Journey criticality — how many journeys, if paused for a week, would cause a revenue or compliance problem.
- Organisational readiness — does a Data 360 implementation exist, and do the marketing and platform teams already work together?
Low scores across the board mean a project. High scores mean a programme with a phased plan. A mixed picture — which is the common case — usually points at hybrid.
Part three: the four paths
Path A — Greenfield
Who: light or no Engagement usage, new business units, new brands, new regions.
Why: you avoid building legacy you would only have to unwind. The learning curve is real, but it is a curve you will climb eventually.
Risk: a newer platform surface means some patterns are still settling. Budget for that rather than being surprised by it.
Path B — Hybrid coexistence
Who: a working Engagement estate and genuine appetite for agentic or unified-data use cases.
Why: existing journeys keep running while new use cases are built on the new foundation. You learn on something small and reversible.
Risk: two orchestration layers, both able to message the same person. This requires an explicit contact-ownership rule, not good intentions.
Path C — Phased replacement
Who: committed to the move, with a large estate and a multi-quarter runway.
Why: migrate by business domain — one brand, one region, one lifecycle programme at a time — with a defined cutover per phase.
Risk: phase fatigue. Programmes that run past four quarters lose sponsors. Sequence the visible wins early.
Path D — Deliberate deferral
Who: heavy custom code, business-critical journeys, no Data 360 foundation, and no use case that Engagement cannot serve.
Why: because there is no deadline, and moving without a data foundation reproduces your current problems on a newer platform.
Risk: deferral becomes drift. Which is why this path has homework.
Deferral is only legitimate with a written trigger
“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.
Part four: the readiness gate
One question outranks everything else: is there a Data 360 model that 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 work. If no, that is your project — and the good news is that it is worth doing regardless of the migration decision. A unified data foundation pays back in Engagement, in Sales Cloud, in Service, and in reporting. It is the least regrettable investment on the whole roadmap.
This is why “should we migrate?” is so often the wrong first question. The right first question is “what would we need to be true for a migration to go well?” — and the honest answer usually points at data, not at journeys.
Part five: what a readiness assessment produces
A useful assessment ends with six artefacts, not a recommendation slide:
- The five inventories, in a spreadsheet the team can maintain.
- A complexity score with the reasoning behind each dimension.
- A recommended path with the two paths that were rejected and why — this is what survives a steering committee.
- A phase plan if the path is B or C, with the first phase scoped to something deliverable in a quarter.
- The data foundation gap stated as work, with an order of magnitude.
- Trigger conditions and a review date, whatever the recommendation.
Everything on that list is defensible in front of a CFO, which matters more than most technical documents admit. Migration business cases fail on vagueness far more often than on cost.
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. That is a few weeks of work, and it converts the largest open question on your marketing roadmap into a plan with dates on it.