So You've Been Told to Move to Marketing Cloud Next

Seven things a marketing executive running a mature, multi-brand Marketing Cloud Engagement stack should verify before signing off on a timeline.

Marketing Cloud Next is being pitched as an upgrade - faster AI, unified data, a modern interface. For a lot of organizations, that pitch is fair. For a mature, multi-brand enterprise running years of AMPscript, custom integrations, and business-unit-specific automation, it's a different kind of project wearing an upgrade's clothing.

That distinction matters because Salesforce frames the move as a "convergence," not a migration. Legacy Marketing Cloud Engagement (MCE) has no announced sunset date, and MCE+ lets both systems run in parallel while you adopt Marketing Cloud Next (MCN) at your own pace.

So before your team commits to a timeline someone else set, it's worth asking what actually has to change underneath - and what doesn't have to change yet at all. Here's where to start looking.

1. Inventory what doesn't port

Marketing Cloud Next added AMPscript support in the Summer '26 release, but it's a subset of the language - roughly 40 functions covering presentation-layer tasks like conditionals, string handling, and date or currency formatting. Data Extension operations, CloudPage functions, and HTTP callouts aren't supported, and Server-Side JavaScript still isn't available at all. So the audit isn't "does AMPscript work" anymore - it's function-by-function. Catalog your AMPscript-heavy templates and CloudPages, your Journey Builder and Automation Studio footprint, and every external system feeding a Data Extension via SFTP, API, or webhook.

2. Check your scripts function by function, not language by language

Don't assume a template either fully works or fully doesn't. Run each script against Salesforce's supported-function list, since the gap is usually a handful of calls - a Data Extension lookup here, an HTTP callout there - inside an otherwise portable template. This exercise usually reveals the real size of the migration: smaller than feared, or bigger than hoped, but rarely what the roadmap deck implied.

3. Map your multi-brand hierarchy onto the new model

If you're running an enterprise parent Business Unit with child BUs per brand, don't assume that structure carries over as-is. MCN introduced business units with the '26 release, and they can partition data, content, and channels by brand, but they work differently than MCE's in a few important ways.

• MCN's business unit construct is non-hierarchical, making anything that relies on inherited content or permissions more complex.
• Each business unit is tied to exactly one Data Space, so brand partitioning is really a data-layer decision. Marketing data objects also include data from every business unit until per-unit filters are applied, which means cross-brand data exposure is a default you have to configure away.
• Content workspaces replace Shared Content, and these workspaces cannot be shared between MCN business units.
• Business unit counts are capped, and units beyond what's included with your edition are a paid add-on, so confirm the current limit and pricing against your contract.

4. Trace consent and suppression by brand

Different BUs likely carry different opt-out and regulatory logic for marketing messaging, and consent often isn't managed in Marketing Cloud alone. If an external system feeds opt-outs or deletion requests into your stack today, map that flow end-to-end, because the mechanics change in MCN, and neither consent nor "Right to Delete" ("Right to be Forgotten") is a simple lift.

Consent is a redesign, not a copy:

• MCN is a strict opt-in system: any contact without a consent record is treated as opted out. Existing consent has to be imported and mapped into MCN's subscription model up front, or your current audience stops receiving marketing.
• Subscriptions are hard to undo. They can't easily be removed once consent records are linked to them, so the subscription structure needs to be designed deliberately, brand by brand, before anything is loaded.
• Consent now lives in the Data 360 data model, and changes take time to sync. External signals need to arrive through supported paths like consent imports, flow actions, or connectors, not direct writes to the consent objects, which can leave the consent check reflecting stale values.

"Right to Delete" is where mature orgs should expect the most friction:

• Deletion requests are submitted through Data 360's Consent API and processed asynchronously, then reprocessed on a recurring schedule to catch data that arrived afterward. "Done" is no longer a single moment you can confirm.
• A deletion request only removes data tied to the individual's profile. Anything not modeled to that individual, such as custom objects, legacy tables, or data flowing in from other systems, can survive the request. In MCE, you could point a delete at known Data Extensions. In MCN, completeness depends on how well your entire data model is connected to the individual, which is much harder to prove to an auditor.
• Requests have to be submitted in every connected system, not just Marketing Cloud. If a third party currently triggers deletions into your stack, that integration needs to be redesigned, not just repointed.
• During a bridge period, consent changes and deletions have to reach both MCE and MCN, and the two platforms identify people differently. MCE's global unsubscribe status can also override changes made in MCN, so a request that succeeds in one system and quietly misses the other is a compliance gap.

Pick one suppression list and one deletion scenario, run them through a sandbox, and confirm they still hold after the data model changes.

5. Plan for new deployment and governance tooling

Deployment workflows built around MCE's tooling don't carry over cleanly. MCN runs on the Salesforce Platform's native metadata model, so environments, release management, and access control all follow platform patterns instead of Marketing Cloud ones. Treat governance as its own workstream, separate from, and likely on a different timeline than, the marketing logic itself.

• Environments: MCN uses true Salesforce sandboxes rather than a test business unit. Each sandbox needs its own authenticated sending domain, From addresses, and tracking domains, and marketing content doesn't always copy over automatically, so a realistic test environment takes real setup.
• Release process: Changes are promoted between environments with Salesforce Platform DevOps features such as change sets, and MCN supports third-party tooling like Jenkins and GitHub. Whatever your team uses to promote changes in MCE needs a new release process.
• Access and approvals: Permissions are managed through Salesforce permission sets, starting with the standard Marketing Cloud Admin and Manager sets. Someone who can build campaigns may still be unable to configure data, sending, or consent, so decide who can build, approve, and activate for each brand instead of carrying MCE roles over as-is.
• Cutover period: If MCE and MCN run in parallel, you'll govern two sets of environments and two ways of promoting changes at once.

6. Consider the bridge, not the leap

Given everything above, this won't be a single cutover on a single date. Plan for a cutover period in which MCE and MCN run side by side, and design for it. For personalization-heavy orgs, the practical approach is phased coexistence on MCE+MCN: keep sends running on the legacy MCE engine while using MCN's Campaign Flows for higher-level orchestration, then move workloads over in stages as each one is verified. You get the new capabilities without rebuilding every template on day one, and without betting the business on one switchover.

Staging the move also buys you a few things:

• Consent management doesn't need to migrate yet. It can keep running in MCE while you design the MCN subscription model.
• Data architecture powered by third-party integrations can keep running out of MCE for the time being, so those integrations aren't rebuilt before they have to be.
• You can prove the data layer early. Run identity resolution against real subscriber data and see actual Data 360 consumption while MCE keeps sending.
• You can move one business unit at a time. Start with a lower-risk BU, apply what you learn to the rest, and keep MCE as the fallback if a workload doesn't behave.

7. The data layer is the real migration

This is the part that actually determines your timeline and budget. MCN replaces MCE's batch-based CRM syncs and scattered per-BU Subscriber Keys with Data 360 (formerly Data Cloud) - a real-time, unified customer profile sitting on the Salesforce core. For a multi-brand org, that means identity resolution has to work across brands, not within each one separately, and it needs to be proven, not assumed: ingest real subscriber data into a sandbox, run identity resolution rules, and reconcile the resulting unified profile count against your actual active subscriber base. Get this wrong and every suppression list, every send, and every "single customer view" claim built on top of it is wrong too. It also comes with its own cost model - Data 360 runs on usage-based credits, and for an org with this volume of automation, that's a real budget line, not a rounding error to discover after signing.

The bottom line for the marketing exec

The platform pitch says "upgrade." The architecture says "re-platform, on your own schedule, with your old system still running underneath you" - and the data layer is where that re-platforming actually lives. Treat it that way, and it becomes something you can plan around instead of something that surfaces mid-migration.

Frequently Asked Questions

Is Salesforce retiring Marketing Cloud Engagement?

Not on any announced schedule. Salesforce frames the move to Marketing Cloud Next as a convergence rather than a migration, and Marketing Cloud Engagement has no announced sunset date. MCE+ lets both platforms run in parallel so you can adopt Marketing Cloud Next at your own pace.

Does AMPscript work in Marketing Cloud Next?

Partially. The Summer '26 release added a subset of roughly 40 AMPscript functions covering presentation-layer tasks like conditionals, string handling, and date or currency formatting. Data Extension operations, CloudPage functions, and HTTP callouts are not supported, and Server-Side JavaScript is not available, so templates need to be audited function by function.

Do Marketing Cloud Engagement business units carry over to Marketing Cloud Next?

Not as-is. Marketing Cloud Next business units are non-hierarchical, each is tied to exactly one Data Space, content workspaces replace Shared Content and cannot be shared between business units, and business unit counts are capped by edition. Multi-brand orgs need to remap their parent and child structure deliberately.

How does consent work in Marketing Cloud Next?

Marketing Cloud Next is a strict opt-in system: any contact without a consent record is treated as opted out. Existing consent has to be imported and mapped into the subscription model before launch, consent lives in the Data 360 data model, and external signals need to arrive through supported paths such as consent imports, flow actions, or connectors.

Can Marketing Cloud Engagement and Marketing Cloud Next run at the same time?

Yes. A phased coexistence on MCE+ lets you keep sends running on the Marketing Cloud Engagement engine while using Marketing Cloud Next Campaign Flows for orchestration, then move workloads over one business unit at a time. During that period, consent changes and deletions must reach both platforms.

What is the biggest part of a Marketing Cloud Next migration?

The data layer. Marketing Cloud Next replaces batch CRM syncs and per-business-unit Subscriber Keys with Data 360, a real-time unified customer profile. Identity resolution has to be proven across brands in a sandbox, and Data 360 runs on usage-based credits, which makes it a real budget line.