Marketing Cloud Next and Engagement: which one you are actually being sold

Quotes reach us with a line item that reads, in full, Marketing Cloud. That phrase currently maps to two live Salesforce platforms sitting under one recently renamed umbrella, and the distance between them is not a version number. One is what you would build on if you were starting today. The other is what a great many organisations already run, and will keep running for years.

The confusion is not the buyer's fault. A rename and a second platform arrived in the same stretch of time, and the vocabulary people had already learned was never retired. The practical result is that a salesperson, a partner and an internal stakeholder can each say Marketing Cloud in the same meeting and mean three different things without anyone noticing.

This is about working out which one is in front of you, which one you already own, and what moving between them actually involves.

#The names, in the order they happened

Take the naming first, plainly, because half the confusion dissolves once the words are sorted.

The Salesforce marketing page is now titled Marketing Software by Agentforce Marketing (formerly Salesforce Marketing Cloud). So the umbrella brand is Agentforce Marketing, and Salesforce Marketing Cloud is the name it used to carry. That is a brand-level change: it renames the family, not any single product inside it.

Underneath the umbrella, Marketing Cloud Next is the current platform. It is sold in two editions: Marketing Cloud Next Growth Edition and Marketing Cloud Next Advanced Edition.

Marketing Cloud Engagement is the earlier platform, and it still exists. It is not a retired label for the same thing, and an organisation running it is running a real product rather than a legacy skin over the new one.

That is the whole vocabulary. An umbrella brand, a current platform, two editions of it, and an earlier platform still in market. Every muddled conversation about this reduces to someone using one of those four terms as though it meant one of the others.

#Two platforms, not two release numbers

The distinction that actually costs money is this one, and it is easy to miss because the naming does not signal it.

Marketing Cloud Next and Marketing Cloud Engagement coexist. They are not two points on a single upgrade path where the older one becomes the newer one after a release window. An organisation sitting on Engagement is not queued for anything. Nothing arrives overnight and converts the estate.

That matters for three reasons.

First, nobody is being moved on a timetable they did not agree to. If your Engagement build works, works is a defensible position, and it should be argued on its merits rather than conceded because the newer name sounds inevitable.

Second, moving is a project, not a switch. What you built in one is not automatically present in the other. Journeys, templates, data structures, integrations, the accumulated logic in your sends: all of that is configuration in a specific product, and configuration does not travel between products on its own.

Third, the two can be compared on merit rather than on recency. Once you stop treating one as the successor of the other, this becomes an ordinary platform decision with ordinary criteria, which is a far more productive conversation than one framed around not being left behind.

#The comparison

Two rows in that table are deliberately non-committal, and that is the honest state of the information rather than caution for its own sake. Packaging and pricing move, and the Salesforce marketing pricing page is the only source that is current by definition. Anything else, this article included, is a snapshot.

#What per-org pricing tells you

Marketing Cloud Next Growth Edition is published at US$1,500 per org per month, billed annually. The number is worth noting. The unit is worth thinking about.

Most Salesforce licensing is per user. Per org is a different shape, and it changes the internal politics of access. Under per-user pricing, every additional person who wants into the marketing platform is a line item, so access gets rationed, and rationing access is how organisations end up with two people who can build a journey and a queue of colleagues behind them. Under per-org pricing that particular argument does not arise in the same form.

The consequence is not that access should be unlimited. It is that the constraint on who gets in becomes governance rather than budget, and governance has to be designed on purpose because the licence is no longer doing it for you by accident. Who can send to the whole database, who approves, who can define a segment: those become deliberate decisions rather than the residue of how many seats finance signed off.

Two caveats. Growth Edition is one edition, and Advanced Edition is priced separately. And a per-org headline rarely means everything is included, so the useful question in a commercial conversation is not what the platform costs, it is what the platform costs including the things we have just agreed we need.

#Who Marketing Cloud Next suits

The clearest fit is an organisation with little to lose in the move.

Greenfield is the obvious case: no existing marketing platform, or one being replaced anyway. There is no sunk build to argue about, so the decision is a straight assessment of the current platform against the requirement, which is exactly the decision the vendor material is written to support.

The second case is subtler and more common than teams expect. An organisation has Engagement, has had it for years, and uses a fraction of what was built. Somewhere in the estate are journeys nobody has audited since the person who wrote them left. Rebuilding forty live assets is a project. Rebuilding four hundred, of which forty matter, is a much smaller project once somebody has been given permission to do the audit and say so out loud.

The third case is where the marketing requirement is genuinely entangled with the rest of the Salesforce estate, and where unified customer data is the thing standing between the current state and the intended one. That is a Data 360 conversation as much as a marketing platform one, and the sequencing advice we give there is set out in Data 360 implementation best practices.

#Who stays on Marketing Cloud Engagement

The strongest reason to stay is the least glamorous one: a large, working estate that the team understands, tuned over years, with the integrations already built and the edge cases already found.

That accumulated knowledge is real value even though nothing on a balance sheet records it. The person who knows why one particular send goes out at an odd hour, and what breaks if it does not, is holding institutional knowledge that does not transfer with a data export. Migrations lose that first and discover the loss later.

Deep integration is the second reason. If Engagement is wired into a warehouse, a preference centre, an ecommerce platform and three internal systems, every one of those connections is in scope for a rebuild. Integration is usually the largest and least visible line in a migration estimate, and it is the one that gets underestimated because the original build happened gradually and nobody remembers it as a single cost.

The third is timing, which is not a technical argument and is often the right one anyway. A platform migration consumes the marketing team for its duration. If the next four quarters carry a rebrand, a peak trading period or a regulatory deadline, the platform decision is not urgent and the calendar decision is.

#A move is a migration, and should be scoped as one

Where organisations get hurt is when a move is presented, internally or externally, as an upgrade.

Upgrade implies continuity: the same thing, newer, with your work intact. Migration implies rebuild, re-test and re-approve. The commercial conversation frequently sounds like the first while the delivery reality is the second, and the difference shows up as a schedule that was set before anyone counted the assets.

Scope it as a migration and the shape becomes familiar. Inventory what exists and, separately, what is actually used, because those two lists are never the same and the gap between them is the biggest single lever on effort. Decide asset by asset whether it is rebuilt, replaced or retired, with retired treated as a real answer rather than an admission of failure. Rebuild integrations rather than assuming they port. Re-test deliverability, because sending reputation attaches to infrastructure and history, not to your intentions. Run both platforms in parallel long enough to prove the new one before the old one is switched off, and budget for that overlap rather than discovering it.

The general principle underneath all of that, and we would call it a principle rather than a documented product behaviour, is that marketing platform migrations are mostly not technical projects. They are inventory, decision and approval projects with a technical component. The Salesforce marketing automation guide is useful for framing what the platform is meant to do; it will not tell you which of your four hundred assets deserve to survive.

#Why which is better is the wrong question

The comparison people ask for is feature against feature. It is the wrong instrument, because both platforms will do the ordinary work of a marketing team, and the ordinary work is most of the work.

The question that actually decides the outcome is what your existing investment is worth. Not what it cost, which is gone either way, but what it would cost to reproduce and what you would give up by walking away from it. An organisation with a modest, poorly documented build has very little to lose and should evaluate the current platform on its merits. An organisation with a deep, well-run, heavily integrated build is holding something expensive, and the case for moving has to clear that bar rather than the bar of being newer.

Framed that way, the decision stops being about Salesforce and starts being about you, which is the only framing that survives contact with an implementation.

The same discipline applies to the AI capability the Agentforce Marketing brand points at. Agentic features are the reason many of these conversations start, and they are worth wanting. They are also worth scoping the way we would scope any agent work, against grounded data and a defined set of tasks, which is the argument in what separates an Agentforce rollout that is still running in six months.

#What to ask before you sign

Four questions, in this order, and none of them are adversarial. They are the questions that turn an ambiguous quote into a clear one.

Which platform is this quote for, Marketing Cloud Next or Marketing Cloud Engagement? Ask for the answer in the document, not in a meeting. This one question resolves most of the ambiguity in the market.

If it is Next, which edition, and what is not included? Growth and Advanced are different commitments, and the gap between the headline and the working configuration is where budgets go wrong.

If we already run Engagement, what specifically happens to what we have built? The useful form of that answer names assets and integrations. If it does not, the migration has not been scoped yet.

What is the pricing basis, and what changes it? Per org for Growth Edition is unusual enough to be worth confirming in writing and modelling against your real growth assumptions.

#The decision, in one line

If you have little built, evaluate Marketing Cloud Next on its merits and ignore the naming history entirely. If you have a lot built and it works, the burden of proof sits with the move, not with staying.

Whichever way it goes, get the name of the platform onto the document before anyone signs anything. The rename made that necessary, and it costs nothing to insist on it.