If you’re coming from the Salesforce platform, you’re probably expecting a familiar deployment process. You build your solution in a sandbox, test it thoroughly, deploy everything to Production using Change Sets or DevOps tools, run a few validation tests, and you’re ready to go live. That expectation doesn’t quite match the current reality of Marketing Cloud Next. Over the past few weeks I had the opportunity (or challenge) to deploy a complete Marketing Cloud Next implementation to Production. What initially looked like a standard deployment quickly turned into multiple support cases, engineering investigations, and many conversations with Salesforce Support. Along the way we uncovered several behaviors that are either undocumented, only partially documented, or simply very different from what Salesforce professionals are used to.

This article summarizes those findings. It combines Salesforce’s published Known Issues, official guidance received directly from Engineering teams, and practical lessons learned during a real implementation.

Marketing Cloud Next Is Not Just Salesforce Metadata

One of the biggest assumptions many architects make is that Marketing Cloud Next behaves like the rest of the Salesforce platform. Since emails, landing pages, forms, and flows all live inside Salesforce, it’s natural to assume that they can all be deployed together through Change Sets or DevOps pipelines. Unfortunately, that isn’t the case today. Marketing Cloud Next currently uses several different deployment mechanisms depending on the asset type. Some components are deployed using metadata, others through CMS Import/Export, while others still require manual recreation in the target org. A single customer journey can therefore require multiple deployment techniques, and even then not every relationship between components is preserved automatically. This is probably the biggest mindset shift teams need to make before starting their first Marketing Cloud Next implementation.

The Current Known Issue

Salesforce has already acknowledged one of the biggest deployment challenges through an official Known Issue. When deploying Marketing Cloud Next components from one org to another using CRM Change Sets, deployments may only complete partially. While many metadata components deploy successfully, others, particularly Flow Versions and certain CMS components, fail with errors such as Invalid Template ID or generic “Unexpected Error” messages. The surprising part is the current workaround provided by Salesforce:

Create the needed assets from scratch in the target org.

Seeing “manual recreation” as the official workaround for enterprise deployments is probably not what anyone expects from a Salesforce platform. However, it is important to understand this limitation early because it has a direct impact on project timelines, testing strategy, and release planning.

Every Asset Type Has a Different Deployment Story

One thing that became increasingly obvious during our implementation is that there isn’t a single deployment process for Marketing Cloud Next. Every CMS asset behaves slightly differently.

Images are the simplest example. Images have no additional prerequisites and can be deployed directly without special considerations. If every component behaved like images, this article would be much shorter.

Landing Pages are significantly more complicated. Salesforce confirmed that they can be deployed either through Change Sets or through the CMS Import/Export functionality. However, neither approach automatically resolves missing dependencies. Before importing or deploying a landing page, every referenced asset, including emails, forms, flows, and images, must already exist in the destination environment. Otherwise publishing may fail or the page may not function correctly. Salesforce also specifically recommends not publishing imported landing pages automatically. Instead, the content should first be imported without publishing, all dependencies should be verified manually, and only then should the landing page be published. This extra validation step helps avoid some of the publishing failures we experienced during deployment.

Forms introduce another layer of complexity because they are closely tied to Salesforce Flows. The deployment process recommended by Salesforce starts by exporting the Form from the CMS Workspace. The Flow itself then needs to be deployed separately using either SF CLI, metadata deployment, or Change Sets. Once the Flow exists in the target environment, the Form can be imported. However, the process doesn’t end there. After import, the Form still needs to be manually linked back to the correct Flow before it can be validated and published. This relationship is not automatically restored during deployment. This is an important detail because it demonstrates a recurring theme throughout Marketing Cloud Next deployments. Moving individual components is only part of the work. Rebuilding the relationships between those components is often equally important.

Flow Deployment Is Better, But Still Not Reliable

Flows should be one of the easier components to deploy. Salesforce recommends deploying them using metadata through either SF CLI or traditional Change Sets. Unfortunately, the official Known Issue also lists Flow deployments among the components that currently experience failures. Some Flows deployed successfully without any intervention. Others failed entirely. In several cases the deployment technically completed, but internal references still pointed back to sandbox specific records, making the Flow unusable in Production until those references were manually corrected. As a result, we eventually made the decision to manually recreate several Flows rather than continue troubleshooting deployment failures. While not ideal, it became the faster and lower risk option given our go live timeline.

The Biggest Surprise: Dynamic Content Does Not Deploy

The most unexpected discovery during our implementation involved email Dynamic Content. After noticing that imported emails had lost all Dynamic Content variations, we initially assumed this was another deployment bug. A support case was raised and the final response surprised everyone involved. Salesforce confirmed that this behavior is working exactly as designed. When an email is exported from one org and imported into another, only the base email content is transferred. Dynamic Content variations are intentionally excluded from the deployment. The official deployment process after importing an email is therefore to verify that the required data source exists in the destination org, manually recreate every Dynamic Content variation, validate previews, and finally publish the email. This is not considered a platform defect, it is the current product design. For a simple email containing one or two personalization rules this may only take a few minutes, but for enterprise implementations the impact can be much greater.

Dependencies Matter More Than You Think

Perhaps the most important lesson from this project was how interconnected Marketing Cloud Next assets are.

• Landing Pages reference Forms.
• Forms reference Flows.
• Emails reference Data Sources and Dynamic Content.
• Templates reference other CMS assets.
• Flows reference various Salesforce objects and metadata.

Unlike traditional metadata deployments where dependencies are usually resolved automatically, Marketing Cloud Next currently expects implementers to understand and manage many of these relationships themselves. A deployment can appear successful while still leaving multiple broken references behind. Because of this, validating dependencies before publishing became one of the most important steps in the deployment process.

Final Thoughts

Marketing Cloud Next is evolving rapidly and introduces many exciting capabilities, but its deployment story is still catching up. Today, moving a solution from Sandbox to Production should not be viewed as a simple technical deployment. It is a migration exercise that requires careful planning, detailed validation, and, in many cases, manual reconstruction of parts of the solution. You should budget significantly more time for deployment than you think you will need. Test the deployment process early in the project, not just before go live. Understand which assets can truly be migrated, which relationships need to be restored manually, and which components may need to be recreated altogether. Your first Marketing Cloud Next deployment is unlikely to be the straightforward metadata deployment you are used to. However, knowing the current limitations before you begin can save days, or even weeks, of frustration later.