Marketing Cloud Next: Choosing the Right First Use Cases and Business Unit Strategy
- sfmcstories
- Aug 16
- 7 min read
Article 1.4: Salesforce Marketing Cloud Engagement/Account Engagement to Salesforce Marketing Cloud Next
In the previous articles in this series, we established the foundation for adopting Marketing Cloud Next, explored the next-generation capabilities available to Marketing Cloud Engagement customers, and looked at the broader path toward Agentforce Marketing.
Now comes the practical part.
Once the foundation is ready, what should you actually start with?
For organizations coming from Marketing Cloud Engagement/Account engagement, this question is more important than it may initially appear.
You may have multiple business units, years of customer data, existing campaigns, automations, and established marketing processes. Marketing Cloud Next introduces a different model for organizing marketing activity around Salesforce and Data 360.
The first 60 days should therefore focus on two things:
Choose the right low-lift use cases.
Establish the right business-unit strategy.
Getting these two decisions right can make the difference between a controlled adoption journey and unnecessary complexity later.
Low-Lift Does Not Mean Low-Value
When we talk about low-lift use cases, the objective isn't to choose something insignificant.
The objective is to choose something that can be implemented quickly while still demonstrating meaningful value.
For an organization moving from Marketing Cloud Engagement/Account engagement, the best starting point is often a use case that the marketing team already understands.
They shouldn't have to learn:
A completely new business process
A completely new campaign strategy
A new audience definition
A new customer experience
at the same time as they are learning Marketing Cloud Next.
Instead, keep the business problem familiar and introduce the new platform experience gradually.
This creates a much smoother learning curve.
Think familiar business problem, new platform experience.
For example, if a business unit already executes a particular campaign regularly, that campaign may be a better candidate for the first Marketing Cloud Next implementation than an entirely new and highly sophisticated marketing initiative.
The team already understands the objective.
The adoption exercise then becomes focused on how Marketing Cloud Next can execute that objective.
Four Traits of a Successful Low-Lift Use Case
Not every use case is suitable for the first 60 days.
A strong candidate generally has four characteristics.
1. Build on Familiarity
The first use case should be something the team already knows.
This reduces the number of variables being introduced simultaneously.
If marketers already understand the audience, campaign objective, content and expected outcome, they can focus their attention on learning the Marketing Cloud Next experience.
This is especially useful when introducing new concepts around campaigns, segments, flows, data spaces, and business units.
The goal is to make the first experience feel achievable.
2. Reuse What You Already Have
A move to Marketing Cloud Next does not automatically mean everything from Marketing Cloud Engagement needs to be recreated.
Look at the assets and data that already exist.
Depending on the use case, this could include:
Existing Engagement data
Data Extensions
Customer attributes
Existing audience definitions
Existing campaign information
Content
Existing marketing processes
Existing integrations
The question should not be:
“What do we need to rebuild?”
Instead ask:
“What can we leverage from what already exists?”
This is particularly important during the first 60 days because reuse reduces both implementation effort and change fatigue.
Salesforce supports synchronizing Engagement Data Extensions into Marketing Cloud Next so that existing Engagement data can continue to support existing processes while also being used for Next experiences such as campaigns, segments, and flows.
3. Start With Recommended Features
The first implementation is not the right time to explore every possible customization.
Start with the capabilities recommended for the use case.
This gives the team an opportunity to understand the standard Marketing Cloud Next experience before introducing additional complexity.
Think of the first implementation as establishing a reference pattern.
Once the team understands the standard approach, you can make informed decisions about where customization is actually necessary.
4. Start With Standard Configurations
This is closely related to the previous principle but deserves separate attention.
A common reaction during migration is to reproduce the old implementation as closely as possible.
That can result in bringing legacy complexity into a new platform.
Instead, ask:
Can the business requirement be met using the standard configuration?
If the answer is yes, prefer that approach for the initial use case.
The first 60 days should be about learning the platform's standard capabilities—not rebuilding every historical customization.
The Business Unit Question
Use-case selection is only half of the decision.
The next question is:
Where should we implement the first use case?
This is where the existing Marketing Cloud Engagement Business Unit structure becomes important.
Organizations with Marketing Cloud Engagement often already have a Business Unit hierarchy representing brands, regions, markets, products, or operational teams.
Marketing Cloud Next introduces a different Business Unit model.
In Marketing Cloud Next, a Business Unit is associated with a Data Space, which provides the data boundary for that marketing context. Salesforce recommends a 1:1 architecture for customers coming from Marketing Cloud Engagement: each MCE Business Unit should initially map to a corresponding Marketing Cloud Next Business Unit/Data Space.
This makes Business Unit strategy an important architectural decision—not just an administrative setup task.
Start With One or Two Business Unit Pairings
For the initial adoption phase, resist the temptation to connect every existing MCE Business Unit immediately.
A more controlled approach is to begin with one or two MCE Business Unit → Marketing Cloud Next/Data Space pairings.
This allows the organization to validate:
Data availability
Business Unit behavior
Audience usage
Content access
Campaign execution
User experience
Governance
Operational processes
before expanding the model.
Salesforce's guidance similarly recommends beginning with one or two Business Unit pairings for existing Marketing Cloud Engagement customers.
This gives you a contained environment in which to learn.
Why 1:1 Mapping Is the Safer Starting Point
A 1:1 mapping means:
One MCE Business Unit
↓
One Marketing Cloud Next Business Unit
↓
One Data Space
This is a simple model to understand and govern.
It also gives the organization a clear boundary around the data and marketing activity associated with that Business Unit.
More importantly, it gives you flexibility later.
You can add additional mappings as your architecture evolves.
Salesforce specifically recommends establishing the 1:1 model first and expanding from there when necessary.
Be Careful With Multi-Mapping
Marketing Cloud Next provides flexibility beyond a simple 1:1 architecture.
A single MCE Business Unit can be mapped to multiple Data Spaces in certain architectures.
That flexibility can be valuable—but it should be intentional.
For example, organizations may eventually have a requirement for consolidated visibility or more complex organizational structures.
However, introducing multi-mapping too early can make the architecture harder to understand.
The question should therefore not be:
“Can we map this Business Unit to multiple Data Spaces?”
The better question is:
“Why do we need this mapping, and what business outcome does it enable?”
Start simple.
Add complexity only when there is a clear requirement.
One Important Consequence of Removing a Mapping
There is another architectural consideration that is easy to overlook.
Business Unit mappings are not simply connection settings that can be changed without consequences.
When an MCE Business Unit mapping is removed, the historical Marketing Cloud Engagement data associated with that mapping is removed from the corresponding Marketing Cloud Next Business Unit.
That can affect use cases that depend on that historical data. Salesforce explicitly calls this out in its guidance for existing Engagement customers.
This is why the initial mapping decision should be treated as an architectural decision rather than something to configure casually.
Before establishing or removing mappings, understand:
What historical data is being exposed
Which use cases depend on it
Which segments depend on that data
Which campaigns depend on those segments
Whether downstream processes will be affected
Marketing Cloud Next Business Units Are Not Simply MCE Business Units With a New Name
This is another important point for teams transitioning from Engagement.
Although the terminology is familiar, the behavior is different.
Marketing Cloud Engagement/Account Engagement uses a hierarchical Business Unit model.
Marketing Cloud Next does not use the same parent-child hierarchy.
Instead, Business Units are associated with Data Spaces, creating a different approach to data and marketing separation.
This means that organizations shouldn't simply copy their existing MCE/MCAE Business Unit hierarchy and assume that the same structure should automatically become the Marketing Cloud Next architecture.
The existing hierarchy should be treated as an input to the design, not necessarily the final design.
A Practical Decision Framework
Before selecting the first Business Unit, evaluate it against four questions.
Business readiness
Does the team have a clear use case that can be implemented within the first 60 days?
Data readiness
Is the required Engagement data available and suitable for the intended use case?
Organizational readiness
Does the Business Unit have stakeholders who are willing to adopt the new experience?
Architectural suitability
Can the Business Unit be mapped cleanly to a Data Space without introducing unnecessary complexity?
If all four are positive, you have a strong candidate.
The Recommended Starting Pattern
A practical starting pattern looks like this:
Existing Marketing Cloud Engagement
MCE BU A
↓
Marketing Cloud Next BU / Data Space A
MCE BU B
↓
Marketing Cloud Next BU / Data Space B
Start with one or two pairings.
Implement a familiar, low-lift use case.
Reuse existing data and components where appropriate.
Use standard Marketing Cloud Next capabilities.
Then observe what happens.
This gives the organization real-world evidence befor--e expanding the architecture.
What Comes After the First Successful Pairing?
Once the first Business Unit is working successfully, don't immediately replicate it blindly.
First capture the lessons.
Document:
Use Case Pattern
What type of use case worked well?
Data Pattern
What Engagement data was required?
Business Unit Pattern
How was the MCE BU mapped to the Next BU/Data Space?
Configuration Pattern
Which standard configurations were sufficient?
Adoption Pattern
What did marketers need to learn?
Governance Pattern
What controls were required?
These become reusable building blocks for the next Business Unit.
The second implementation should therefore be based on a proven pattern, rather than starting from scratch.
The 60-Day Principle
The first 60 days should ultimately answer two questions:
Question 1
Can our marketers successfully execute a familiar business use case in Marketing Cloud Next?
Question 2
Can we establish a Business Unit/Data Space model that can scale without creating unnecessary complexity?
If both answers are yes, the organization has achieved something much more valuable than a single pilot.
It has created the foundation for repeatable adoption.
Final Takeaway
Moving from Marketing Cloud Engagement/Account Engagement to Marketing Cloud Next doesn't mean that the first step should be a large-scale migration.
The smarter approach is to make the first move deliberately small.
Choose a use case the team already understands.
Reuse what already exists.
Prefer recommended features.
Avoid unnecessary customization.
Start with one or two Business Unit/Data Space pairings.
And treat the Business Unit mapping as an architectural decision—not simply a configuration exercise.
Start simple. Learn from the first implementation. Then scale with intent.
That is how the first 60 days can become a repeatable adoption model rather than just another migration milestone.
Comments