Marketing Cloud Next in 2026: The Migration Nobody Is Forcing You To Make

You open an email your team shipped in 2019 and the first thing in the HTML is a forty-line AMPscript block. It runs a LookupRows against a loyalty data extension, checks the row count, reads a tier field, and swaps the hero banner four ways. It has sent every Tuesday for seven years without anyone touching it.

In Marketing Cloud Next, none of those three functions exist.

That single fact is the whole shape of this decision, and it is why the Marketing Cloud Next question keeps getting postponed at every org I talk to. Salesforce has been clear that nobody has to move. That sounds like a kindness. In practice it means the hardest platform decision your marketing team will make this decade has no deadline attached to it, which is exactly the condition under which decisions do not get made.

The thing you would actually be migrating to

Marketing Cloud Next is the umbrella name for the Growth and Advanced editions of Salesforce's marketing platform. It went generally available in June 2025, and the important part is not the feature list. It is the address.

Marketing Cloud Engagement runs on the stack Salesforce bought with ExactTarget in 2013. It has its own login, its own user model, its own API surface, its own deployment story, and its own data layer built on data extensions. It sits beside your CRM and talks to it through a connector. Anyone who has debugged a Marketing Cloud Connect sync at 11pm knows precisely how separate those two worlds are.

Marketing Cloud Next runs on Salesforce core, with Data Cloud (now branded Data 360) as its data layer. Same org. Same users and permission sets. Same Flow engine your admins already build in. Same metadata and deployment tooling. Campaign orchestration is Flow, not a separate canvas in a separate application. Segmentation runs against Data 360 objects rather than data extensions.

That is a genuinely better architecture for most orgs, and I do not say that as a compliment to the roadmap. One identity model, one permission model, one deployment pipeline, and marketing sitting inside the same platform as service and sales is what every integration project of the last twelve years has been trying to approximate with connectors and middleware.

It is also why the migration is expensive. You are not upgrading a product. You are moving to a different platform that happens to share a brand.

Salesforce has not published a deadline, and that is the hard part

Here is the state of play as of Winter '27. Salesforce has published no end-of-life, no end-of-sale, and no end-of-roadmap for Marketing Cloud Engagement. Email Studio, Journey Builder, Content Builder and Automation Studio continue to ship and continue to receive updates. Existing Engagement and Account Engagement customers can turn on Marketing Cloud Next capabilities inside the orgs they already run. Salesforce's own framing is convergence rather than migration.

Anything you read announcing a 2026 or 2027 forced cutover is reading past what Salesforce has actually published.

So the pressure is not a sunset date. The pressure is where the engineering goes. Read the last four release notes side by side and the pattern is not subtle: Marketing Cloud Next got dedicated IP support, custom preference management and multi-business-unit setup in Spring '26, then native RCS and AMPscript in Summer '26. Engagement got maintenance. Account Engagement got almost nothing, and the informed community read, from people who track this release by release, is that its end of sale arrives well before Engagement's.

That is a roadmap telling you something without committing to a date. Two things follow from it, and they pull in opposite directions.

The first is that you have time. Real time, measured in years, not quarters. Nobody is going to switch off your sends.

The second is that "we will decide next year" is itself a decision, and it compounds. Every new Agentforce marketing capability, every new channel, every real-time personalization feature lands on the Data 360 side of the line first. An org that defers for three more years is not holding position. It is accumulating another three years of AMPscript, server-side JavaScript and CloudPages that will need rewriting by a team that will be three years less familiar with why any of it was written.

What ports, what rebuilds, and what has nowhere to go

There is no automated migration tool. Not for templates, not for images, not for journeys, not for automations. Salesforce has not shipped one and has not promised a date for one. Any migration plan that assumes tooling will arrive to do the boring parts is a plan with a hole in it.

The realistic mapping looks like this.

Data extensions become Data 360 objects. This is a modelling exercise, not an export and import. A sends table with 40 columns and an implicit relationship to three other tables has to be expressed against the Individual, Contact Point and Unified Individual models. Some of your columns are attributes. Some are events. Some are denormalised copies that exist because a query was slow in 2018 and should not survive the trip.

Journeys can run in parallel before they get rebuilt. You can orchestrate in Marketing Cloud Next and invoke an existing Engagement journey from it. That bridge is the single most useful fact in this entire migration, and I will come back to it.

Automation Studio SQL has no direct conversion. Every SQL query activity becomes a Data 360 transformation or a Flow. The logic survives. The artifact does not. Orgs with 200 scheduled automations should read that sentence twice.

Content rebuilds by hand. Templates, images, content blocks. Manual. Budget for it as a design project, because that is what it becomes the moment somebody asks whether the 2019 template was ever actually on brand.

SSJS and CloudPages have no home. Server-side JavaScript and the CloudPages hosting model do not exist in Marketing Cloud Next. Preference centres, gated content pages, form landing pages and API-driven microsites built on CloudPages are rebuilds against Experience Cloud or an external front end. This is usually the largest single line item and the one that never appears in the first estimate.

AMPscript arrived in Marketing Cloud Next. Your AMPscript did not.

Summer '26 shipped AMPscript support in Marketing Cloud Next, and the ecosystem reaction was relief. Salesforce's own AMPscript reference now describes the language as belonging to both Engagement and Next. Scripting validates in the message editor rather than at send time, which is a real improvement over discovering a syntax error via a test send.

Read the detail and the relief should be narrower than it looked. What shipped is a targeted set of functions, not the library. Community testing puts the working set at roughly forty functions.

More importantly, the supported set is the presentation layer. Conditional logic, string handling, date formatting, currency formatting, variable output: those cross over. The categories that do not cross over are data extension operations, CloudPages functions and HTTP functions.

Look at what that leaves out. Lookup, LookupRows, Row, Field, InsertData, UpsertData. Every function whose job is to go and get something.

This is not an oversight Salesforce will patch next release. It is architectural. There are no data extensions in Marketing Cloud Next to look up. Personalization data reaches the message through Data Graphs, referenced in the template as $dataGraph.FieldName, resolved by the platform before the message renders. The data access model moved from "the email queries at send time" to "the platform hands the email a resolved record".

That is a better design. It is also a different one, and it means the AMPscript that ports is the AMPscript that formats. The AMPscript that does the actual work, the blocks that reach across four data extensions to assemble a personalised offer, does not port. It gets redesigned as a data graph and a segment, upstream of the message entirely.

Which brings the estimate back to reality. Ask your team how many templates contain a LookupRows. That number, not the template count, is your migration size.

The identity model is the real migration

Everything above is work you can see. The identity change is the one that fails quietly, and it is where I have seen these projects actually go wrong.

Marketing Cloud Engagement is organised around the subscriber key. It is a string. You chose it, you enforced it, and everything downstream, suppression, unsubscribes, send logging, journey entry, hangs off it. If your subscriber key is the CRM contact ID, life is reasonably good. If it is an email address, or an ERP customer number, or a concatenation somebody invented in a hurry, you have been quietly managing an identity system by hand for years.

Marketing Cloud Next resolves identity through Data 360. Source records land as data lake objects, map to data model objects, and identity resolution rules collapse them into a Unified Individual. That unified profile is what gets segmented and messaged.

Three failure modes come out of this, and none of them announce themselves.

Match rules that are too loose merge people. Two customers who share a household email address become one profile, and one of them stops receiving mail. Nothing errors. Your send volume just drifts down and nobody can say why.

Match rules that are too tight split people. The same person arrives from the loyalty system and the commerce platform with different keys, does not merge, and gets the welcome series twice. The complaint arrives through support, not through a monitoring alert.

Consent does not inherit the way you assume. Suppression lists, unsubscribes and preference records are keyed to the old identity. Mapping them onto unified profiles is the part of the project that needs a compliance sign-off rather than a developer estimate. Get it wrong in a regulated market and the cost is not a rebuild.

Do this work first, in a sandbox, against real data, before anybody rebuilds a single email. If your identity resolution produces a unified profile count that is wildly different from your active subscriber count, that gap is the project. Everything else is content production. The deduplication and identity resolution guide covers how the matching side of this behaves in more detail.

Four lanes, and you should pick one on purpose

Most orgs treat this as binary: move or do not move. It is not. There are four defensible positions, and the failure mode is drifting between them rather than choosing one.

Stay. You run high volume with a deep scripting estate, dozens of CloudPages, and a working team. The gap between what you do today and what Marketing Cloud Next supports is still wide. Staying is correct. Make it a decision with a review date, not an omission, and stop building new CloudPages while you wait.

Bridge. Orchestrate in Marketing Cloud Next, execute in Engagement. Segments and campaign logic move to Data 360 and Flow, sends still go out through the engine that understands your templates. This is the highest-value lane for most mid-sized and large B2C estates, because it moves the part that benefits from unification without touching the part that is expensive to rebuild. Parallel operation of six months or more is normal here, and that is a feature.

Greenfield. The next brand, region or business unit you launch goes native on Marketing Cloud Next. You get a real implementation with real users, learn the platform's actual limits on something whose failure mode is survivable, and build the internal skills before you commit the flagship. If you are launching anything new in the next year, this is close to free.

Move. Your estate is genuinely simple: a few dozen templates, light scripting, no CloudPages, identity already keyed to the CRM. Move and be done. This is more orgs than admit it, and fewer than the ones who think it is them.

The lane you cannot defend is the one where a strategy deck says Marketing Cloud Next, nothing gets funded, and the team keeps building new AMPscript on the platform the deck says you are leaving.

The ninety-day version

If you want to make this concrete without committing budget, here is what fits in a quarter.

Weeks 1 to 3: count the things that do not port. Not templates. Scripts. Grep your content for LookupRows, Lookup, InsertData and RaiseError. List every CloudPage and every SSJS block. Count SQL query activities in Automation Studio. That list is your migration size, and it is usually a fraction of what people fear or a multiple of what they hoped.

Weeks 4 to 7: model identity in a sandbox. Ingest your real subscriber data into Data 360, write identity resolution rules, and compare unified profile counts against your active subscriber count. Then map one suppression list end to end and confirm a suppressed person stays suppressed.

Weeks 8 to 11: rebuild one journey natively. Pick a real one with genuine branching, not the welcome email. Build it in Flow against Data 360 segments, send to a seed list, and compare against the Engagement version.

Week 12: pick a lane and write it down. One page: the lane, the reason, the review date, and what your team is allowed to build on Engagement in the meantime. That last line is the one that stops the estate growing while you decide.

Ninety days, one team, no licence commitment, and at the end you know your actual number instead of a vendor's.

Do this next

Open your content repository and search every email and CloudPage for LookupRows. Count the hits, and count how many distinct data extensions those lookups touch. If the answer is under twenty templates and under five data extensions, you are a Move or a Greenfield, and you should schedule the sandbox work this quarter. If it runs into the hundreds, you are a Bridge, and the useful next step is proving the orchestration handoff on one journey rather than debating the whole platform. Either way the search takes an afternoon and it replaces a year of speculation with a number. If you are still working out how the current products relate to each other before you plan any of this, the Engagement versus Account Engagement breakdown and the Marketing Cloud Growth Edition guide map the portfolio as it stands.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.