Why assess your Salesforce Marketing Cloud Engagement org now, before you plan the move

If your team runs Salesforce Marketing Cloud Engagement, the move to Marketing Cloud Next is probably already on someone's list. There is no published deadline for it, so the pressing question is not when, but how much work it will be. That is hard to judge from the outside. The two platforms are built on different foundations, so most of what moves is redesigned rather than copied, and every item brings along everything it depends on. This article explains what that means in practice, and why the cheapest time to measure it is before the scope, budget and timeline are agreed.

The two platforms store data differently

In Engagement, most of your data lives in data extensions: tables your team designed, each with its own columns and key. A data extension becomes sendable through a send relationship to the Subscriber Key, and a person is identified by their Contact Key. Opt-outs are kept in All Subscribers and publication lists. Automation Studio and Journey Builder coordinate the work, and SQL queries usually connect the two.

Marketing Cloud Next is built on Data 360 and the Salesforce platform. Data comes in through data streams and is mapped to data model objects. A person is an Individual, and records from different systems are matched by identity resolution rules rather than by one shared key. Audiences are segments, and scheduled work runs in Flow, together with transforms and segment publish schedules.

Because the foundations differ, the useful question for each item is not where it goes, but what it becomes:

The real scope is everything a live item depends on

Moving one journey means moving everything it needs to run. That includes the data extension people enter from, the data its decision splits check, its emails with their templates and content blocks, and any data those emails look up as they send. It also includes whatever keeps that data current: the automation that refreshes it, the SQL inside that automation, the data extensions the SQL reads, and the import or integration that loads them.

A single welcome journey can pull in a chain like this:

Journey  Welcome series                          running
  entry  DE Welcome_Entry
           written by  Automation Nightly_Welcome  (SQL)
             reads     DE Web_Signups         <- Import from SFTP
             reads     DE Contact_Salesforce  <- Marketing Cloud Connect sync
  email  Welcome_1
           looks up    DE Offers_ES

Each step in that chain is design, build and test work in Marketing Cloud Next. So the number that sizes a migration is not how many items a business unit holds, but how many are reached from something still running. The two can be far apart.

Our sample org shows how far. It is modeled on a Marketing Cloud development business unit, with made-up identifiers and volumes scaled to a small-to-medium production business unit. Of its 3,413 items:

• 711 are reached from something running.
• 763 are reached only through journeys and automations that have stopped.
• 1,900 (56%) are orphaned: nothing running references or uses them, and nothing has touched them in 90 days.

The remaining 39 need a closer look: 21 are still written to but never read, and 18 may be referenced in ways that could not be resolved automatically, so a person needs to check them.

A plan built from the full inventory carries all 3,413 items. A plan built from what is running starts at 711, with 763 to review alongside the people who know why they stopped.

Most of the time goes into design, not build

The slow part of a migration is rarely building things in the new platform. It is working out what each live item is for. In an Engagement business unit, important business rules are often undocumented: a filter in a query that excludes one region, a journey decision based on a field an integration stopped filling in, a script that renames a file before an import picks it up. Each one has to be found, explained by someone who knows why it exists, and redesigned before anyone can build it.

Three areas usually carry most of that work:

• Automation Studio. Marketing Cloud Next has no Automation Studio. Each SQL query is rewritten as a transform or as segment criteria rather than copied across. Queries that pass data through several staging tables, remove duplicates, or read shared data from a parent business unit need the most rework.
• Script activities. Server-side JavaScript has no equivalent place to run in Marketing Cloud Next. These scripts often handle housekeeping, such as clearing data extensions, moving files or retrying failed sends, and each one needs an owner and a replacement.
• Journeys that start from Salesforce data. These journeys react to changes in CRM records through Marketing Cloud Connect. In Marketing Cloud Next the trigger is designed against Data 360, so who enters, when they can re-enter, and how fresh the data is are all decided together.

None of these blocks a migration. Each is a decision, and the time it takes depends more on people than on the platform: finding the owner and agreeing on the redesign come before any build.

Running both platforms needs clear boundaries

Salesforce presents Marketing Cloud Next as working alongside Engagement rather than replacing it, so most teams will run both for a while. Data can move in both directions: Data 360 can bring in Engagement data extensions and email engagement data through its Marketing Cloud Engagement connector, and segments built in Data 360 can be activated back to Engagement. Each of those connections has its own keys, schedule and delay, so a plan for running both has to answer three questions:

• Which data extensions should be brought into Data 360, and which can stay behind because nothing running uses them?
• Which journeys keep running in Engagement, and which are rebuilt in Marketing Cloud Next first?
• Which platform is the source of truth for subscription status while both are sending?

With a clear picture of what runs and what each item depends on, these questions have answers a team can stand behind. Without one, running both platforms tends to become a holding area for everything the project did not get to.

What Salesforce has said so far

Here is what is on the public record, with the date each source was checked:

• Marketing Cloud Next complements Engagement. Trailhead: "Marketing Cloud Next doesn't replace Marketing Cloud Engagement—it complements and extends it." The same unit says existing campaigns, automations and templates "continue running as they do today without disruption." (Trailhead, checked October 9, 2026)
• Engagement still receives releases. Salesforce continues to publish release notes for Marketing Cloud Engagement. (Salesforce Help: Marketing Cloud Engagement Spring '26 release notes, checked October 9, 2026)
• Some parts of Engagement are being retired. Salesforce Ben reports that Advertising Studio subscriptions have not been renewable since August 15, 2026, and that Salesforce recommends Data Cloud Ad Audiences instead. (Salesforce Ben, checked October 9, 2026)
• There is no published end date. As of October 9, 2026, Salesforce has not published an end-of-life, end-of-sale or required migration date for Marketing Cloud Engagement. Articles that give a 2026 or 2027 deadline go further than anything Salesforce has said.

So the timing pressure mostly comes from your own calendar: a contract renewal, a budget cycle, or Data 360 work that is already under way. Each of those goes more smoothly when you already know what your business unit runs.

What to know before the plan is written

Before scope, budget and timeline are fixed, a team should be able to answer four questions from evidence rather than memory:

• Which items are used by something running, and which only by things that have stopped?
• Which live items have no equivalent in Marketing Cloud Next, and who decides what happens to each?
• Which data extensions will need to be in Data 360 while both platforms run, and which can stay behind?
• Which references could not be confirmed automatically, such as data extension names built while an email sends, and still need a person to check them?

re:target assess answers these for one business unit, read-only and at no cost. It labels every item, lists the decisions to be made, and gives a complexity band with the reason behind it. re:target never asks for write access to Marketing Cloud Engagement.