AMPscript Arrives in Marketing Cloud Next: What Summer '26 Means for SFMC

One of the most tangible barriers to migrating onto Marketing Cloud Next just fell away. With the Summer '26 release, Salesforce is officially bringing native AMPscript support to its new platform. Teams that have built rich AMPscript templates on Salesforce Marketing Cloud Engagement for the better part of a decade can finally plan a gradual move rather than a full Handlebars rewrite. Here is what it changes for your SFMC migration program, your CRM teams and your existing email assets.

What Salesforce is actually shipping in Summer '26

Marketing Cloud Next was built around Handlebars as its primary templating language, a direct consequence of the Hyperforce architecture and the deep coupling to Data Cloud. AMPscript stayed behind on the older SFMC Engagement platform, which turned every migration project into a wholesale rewrite. The Summer '26 release officially shifts that stance: AMPscript becomes a first-class citizen inside Marketing Cloud Next, side by side with Handlebars.

In practical terms, your teams can pull data from CRM records and subscriber profiles with the familiar AMPscript functions, format dates, currencies and strings with helpers your developers already use such as FormatDate, FormatCurrency and Concat, and mix AMPscript with Handlebars inside a single template to expose new Data Cloud objects progressively, without breaking what already works.

The strategic message is unambiguous: Salesforce is no longer asking you to choose between the old world and the new one. You can migrate audiences, journeys and content at different speeds, which finally makes migration roadmaps realistic for marketing operations teams.

Why this is a turning point for SFMC migration

Until now, three roadblocks compounded for SFMC Engagement customers: the absence of Business Units in Marketing Cloud Next, the cost of rewriting thousands of templates in Handlebars, and the need to reconcile two different data models. Spring '26 fixed the first one with the arrival of Business Units. Summer '26 tackles the second by stabilizing the templating layer.

Cut technical debt without freezing your roadmap

If your templates contain LOOKUPROWS blocks, REST API calls written in AMPscript, or complex conditional structures, you no longer need to budget weeks of refactor before you can even test the new platform. The migration can follow a "lift, then improve" path: move the templates as they are, then modernize the highest-value blocks gradually, in line with business priorities rather than tool constraints.

Protect the knowledge your team already has

The other gain is human. Your CRM project managers, your email developers and your integration partners have been working with AMPscript for nearly a decade. Forcing a hard cut to Handlebars created an obvious operational risk: rendering bugs, ramp-up time, dropped productivity. Native AMPscript support means the technical transition can ride alongside the Handlebars and Data Cloud learning curve rather than running ahead of it.

What it looks like in practice: AMPscript and Handlebars side by side

Here is what a hybrid block can look like. Picture a transactional email that personalizes the greeting with a profile attribute and surfaces a promotion attached to a Data Cloud object:

%%[ VAR @firstName, @lastSeen SET @firstName = AttributeValue("FirstName") SET @lastSeen = FormatDate(AttributeValue("LastLoginDate"), "MMM d, yyyy", "en-US") ]%% Hi %%=v(@firstName)=%%, Your last sign-in was on %%=v(@lastSeen)=%%. {{#with offer}} Today's offer: {{name}} — use code {{couponCode}}. {{/with}}

In this example, AMPscript does what it was always best at in SFMC Engagement: read and format profile attributes. Handlebars handles the new Data Cloud sources, here the offer object, without friction and without an extra round-trip.

A pragmatic migration pattern

A useful pattern is to split each template into three distinct layers. The profile layer stays in AMPscript and handles subscriber attributes, preferences and legacy profile fields. The CRM object layer moves to Handlebars and consumes the new Salesforce Objects sources, which are now reachable without data graphs: cases, opportunities, leads. The presentation layer sits in HTML enriched with Handlebars helpers and handles conditional rendering, loops and final formatting.

That separation makes template audits far easier and lets you plan a graceful exit from AMPscript wherever it no longer adds value.

Pitfalls to anticipate

AMPscript support does not equal full feature parity with SFMC Engagement. Several points deserve attention at the scoping stage rather than at go-live.

Data-manipulation functions

Some functions that are very specific to SFMC Engagement — for instance direct Data Extension manipulation through LOOKUPROWS or CLAIMROW — do not have a direct equivalent inside Marketing Cloud Next, which relies on Data Cloud. Before migrating, identify the blocks that depend on proprietary Data Extensions: they are the ones that will demand the most work and will probably need to be rewritten.

APIs and Web Collect calls

AMPscript calls that talk to SFMC Engagement SOAP or REST endpoints will not run in the same environment anymore. Inventory those dependencies upstream and plan to replace them with the new Data Cloud connectors, with Agentforce server-side flows, or with Cloud Functions triggered from Marketing Cloud Next.

Rendering and visual QA

Plan for a dedicated QA cycle on hybrid templates. AMPscript rendering inside Marketing Cloud Next can differ marginally on HTML escaping, null handling and locale-specific date formatting. Set up a visual diff suite that compares SFMC Engagement and Marketing Cloud Next output on a representative sample of your top sends.

How to prepare your migration right now

If you are still on SFMC Engagement, the right 90-day reflex breaks down into three complementary moves.

1. Map your AMPscript templates

Inventory the templates that matter most, by send volume and by the number of Journeys that consume them. For each one, identify the AMPscript functions used, the Data Extensions queried, and the external APIs called. That diagnostic drives the strategy: lift-and-shift, targeted refactor, or full rewrite. Without that map, the roadmap stays theoretical.

2. Prepare the data layer

Marketing Cloud Next runs on Data Cloud. Even if AMPscript keeps reading profile attributes, the new use cases — cross-channel personalization, RCS, conversational email — flow through Data Spaces. Use the migration as an opportunity to rationalize your data models and expose the right objects on the Data Cloud side, rather than cloning the existing setup row by row.

3. Build a Handlebars skill base in parallel

The goal is not to rewrite everything in Handlebars, but to make sure every team has at least one person who can read, write and debug Handlebars confidently. Without that, you stay stuck with what AMPscript can already do and miss out on the new data sources — Salesforce Objects, Content Variables, Offers — that are exposed exclusively through Handlebars.

Key takeaways

1. AMPscript is now native in Marketing Cloud Next. The Summer '26 release officially secures the language that has powered your templates for a decade.

2. Migration becomes incremental. You can lift the existing assets and then modernize gradually rather than rewriting everything in one big bang.

3. Handlebars is still essential. To use Data Cloud, Salesforce Objects and Offers, your teams need a real Handlebars skill set.

4. Hybrid QA is a new discipline. Plan a dedicated test protocol to compare rendering between SFMC Engagement and Marketing Cloud Next.

5. Now is the time to inventory. A 90-day AMPscript audit is the best investment to scope a credible migration roadmap.

Planning a move from SFMC Engagement to Marketing Cloud Next and want to de-risk your templating strategy? Let's talk through your context. CGC-Agency supports marketing operations teams across the full AMPscript, Handlebars and Data Cloud lifecycle.