START WITH THE CAPABILITY GAP
What needs to work better — and why now?
- Reach peopleAudiences and journeys
- Build trustConsent and content
- Improve performanceFeedback and operations
Before discussing migration, name the marketing capability that is no longer good enough in the current setup.
- Are audiences too slow or difficult to build?
- Are journeys becoming hard to change safely?
- Is consent logic fragmented across platforms or processes?
- Does content production create too much manual work?
- Do campaign teams lack feedback from customer behavior or downstream systems?
- Is the operating model around releases, testing and ownership becoming too expensive?
If the capability gap is vague, the migration case is probably vague too.
DECISION BEFORE MIGRATION
Define the problem before changing the platform.
A platform transition should solve a known business or operating problem. Otherwise the team risks recreating the same complexity on newer technology.
- Which marketing outcome should improve?
- Which current limitation is causing the problem?
- Is the limitation technical, organizational or both?
- What would become simpler for marketing operations after the change?
- Which existing capability can stay where it is for now?
A good migration case explains what will become better — not merely what will become newer.
TIMING MATTERS
Not every capability needs to move at the same time.
Different parts of the marketing operating model may be ready at different times. Audience creation, consent, content, orchestration and reporting do not have to cross the platform boundary in one release.
Sequence the transition around dependencies and measurable value, not around an all-or-nothing target date.
- KeepWhat works well
- ExtendWhere value is missing
- MoveWhen dependencies are ready
Different capabilities. Different timing.
PRODUCT CHANGE ≠ BUSINESS CASE
A new product name is not a migration strategy.
A transition makes sense when the new capability solves a real limitation and the surrounding data, consent, content and operating model are ready to support it.
The migration case should survive even if the product name is removed from the slide.
- Which current capability is no longer fit for the use case?
- Which new capability produces a measurable improvement?
- Which dependencies must move with it — and which can remain where they are?
- What duplicate logic would coexist during the transition?
Further steps (1)
- Who owns the old and new platform while both are running?
- Improve the current setup
- Extend with selected new capabilities
- Stage the transition
THREE VALID OPTIONS
Three realistic paths
There is no universal transition sequence. Most organizations fall into one of three practical patterns.
The data foundation for AI: What Agentforce and Data 360 really need explains the data foundation such a transition requires.
The right path is the one that improves the marketing capability without creating more operating complexity than the change removes.
IF YOU MOVE, MOVE IN CONTROLLED STEPS
Plan a staged transition.
A staged transition works when each step has a purpose, an owner and a clear rule for what remains on the existing platform.
Do not let “temporary coexistence” become a permanent architecture by accident.
- Choose one capability or use case with a strong reason to move
- Define the data, consent and content dependencies around it
- Keep responsibilities explicit while old and new platforms coexist
- Measure whether the new setup actually improves the intended outcome
Further steps (1)
- Retire old logic only when the new path is stable and operationally owned
DECISION CHECKLIST
What should be clear before deciding?
A platform decision should be based on the capability, operating impact and transition cost — not on a feature comparison alone.
Business need
Which marketing capability needs to improve? What business or operational outcome should become measurably better?
Current limitation
What is preventing that improvement today? Is the problem really the platform, or process, data, ownership or operating discipline?
Target capability
Which new capability addresses the limitation? What evidence shows that it is materially better for this use case?
Dependencies
Which data, consent, content and integration dependencies move with it? Which can remain on the current platform?
More criteria (2)
Operating model
Who owns build, testing, release, support and change after go-live?
Retirement
What has to be true before the old logic can be switched off?
If the retirement condition is undefined, the transition is not fully designed.
PROVE THE CHANGE BEFORE EXPANDING IT
Test one new capability before committing to the wider transition.
A focused pilot should prove that the new setup improves a real marketing use case and can be operated without introducing hidden complexity.
01
Take stock
Document how the use case works today, including data, consent, content, journey logic and operating effort.
02
Define the value
Agree what should become faster, easier, more reliable or more measurable.
03
Design the target path
Specify which parts move to the new platform and which responsibilities stay where they are.
04
Operate the pilot
Run the use case through real campaign operations, testing, support and reporting.
05
Decide on the transition
Use the pilot evidence to expand, revise, pause or reject the migration path.
A pilot is useful when it reduces uncertainty about the transition — not when it simply proves that the new platform works.
Common questions about moving to Marketing Cloud Next
Do we need to migrate because a newer Marketing Cloud platform exists?
No. A new platform creates an option, not a business case. Move when the capability gain, operating model and transition effort justify the change for your use cases.
Can the current platform and new capabilities run in parallel?
Yes, if the boundaries are explicit. Consent, audience logic, content ownership, reporting and support should not be duplicated without a clear reason and retirement path.
How do we know whether to move now or wait?
Compare the capability gap with the transition cost. If the current platform still supports the important use cases and the new capability does not yet create meaningful value, waiting can be a sound architecture decision.
Sources and further information
Primary Salesforce documentation and reference material for Marketing Cloud capabilities, transition planning and related platform decisions.
- Salesforce — Marketing Cloud EngagementChecked on
Supports the current assessment of Marketing Cloud Engagement and Next; roadmap, licensing, naming and migration statements are volatile and must be rechecked before publication.
- Salesforce — Marketing Cloud NextChecked on
Supports the current assessment of Marketing Cloud Engagement and Next; roadmap, licensing, naming and migration statements are volatile and must be rechecked before publication.
- Salesforce — Marketing products at a glanceChecked on
Supports the current assessment of Marketing Cloud Engagement and Next; roadmap, licensing, naming and migration statements are volatile and must be rechecked before publication.
Topics in this article
THREE WORKING VIEWS
Three views that make a platform transition traceable.
Configured working examples with fictional records. Each view exposes a specific decision, handoff or review state.
Make audience eligibility explicit
The audience preview separates initial eligibility from later send-time policy checks. Illustrative configured marketing workflow with fictional data; not an exact Marketing Cloud Next interface or a license claim.
Swipe with your finger or drag with the mouse button held down. You can also select an image or use the arrow keys.
Image 1 of 3: Make audience eligibility explicit
Continue reading
Salesforce Data 360: Start with the Use Case, Not the Data
Data 360 becomes useful when the business outcome comes first. Instead of asking which sources can be connected, start with the decision, audience or process you want to improve — then work backwards to the data actually required. That usually leads to a smaller first scope, clearer identity rules and an activation you can measure.
Read article
The Data Foundation for AI: What Agentforce and Data 360 Actually Need
AI and Data 360 do not need every field to be perfect. They do need the important data to mean what teams think it means — with enough ownership, evidence and context to use it safely. The practical goal is not “clean all the data.” It is to make the critical data trustworthy enough for the process you want to improve.
Read article
Quotes in Salesforce: Which Revenue Setup Actually Fits?
Whether standard Salesforce, Revenue/CPQ functionality or a more specialized setup is right depends on the commercial model behind the quote: products, variants, pricing, approvals, contracts and what has to happen downstream. Start with the process and system boundaries. Choose the product after that.
Read article