If you have ever tried to sell ‘Marketing Cloud Next’ to a large multi-brand or multi-region enterprise, you likely encountered the same hurdle every time: “It looks great, but what happens to our business units?” For users of ‘Marketing Cloud Engagement,’ business units are not merely a ‘nice-to-have’ feature; they are the backbone of the system, enabling large enterprises to segregate data, permissions, and sending reputations across distinct brands, regions, or subsidiaries. ‘Marketing Cloud Next‘ launched without this concept. For many large enterprises, this single shortcoming was a deal-breaker that stalled conversations right there: “It’s interesting, but let’s talk again next year.”
That distinction has now been eliminated. ‘Business Unit Partitioning’ has arrived in ‘Marketing Cloud Next,’ significantly altering the approach to large-scale adoption. It does not simply replicate the ‘Marketing Cloud Engagement’ model; instead, it adopts a different approach resembling the long-standing method used in ‘Account Engagement’ (Pardot) – and this distinction is crucial when planning a migration or setting up a brand-new system.
This isn’t a feature announcement recap. It’s a walkthrough of what actually changes in your design decisions once business units are on the table, where the rough edges still are, and what I’d tell a client evaluating this today.
Key Takeaways
- Marketing Cloud Next’s business unit support partitions data and assets in a model closer to Account Engagement than to Marketing Cloud Engagement’s Enterprise 2.0 structure, so migration mapping needs to be explicit, not assumed.
- Confirm exactly what’s isolated per business unit — subscriber data, consent, sending infrastructure, and Data 360 (formerly Data Cloud) objects may not all follow the same isolation rules.
- Treat a Marketing Cloud Engagement migration as a chance to rationalize legacy BU sprawl, not replicate it as-is.
- Business unit design is an organizational conversation first and a configuration task second — get brand, compliance, and CRM ops stakeholders aligned before building anything.
- Pilot with one business unit and real data volume before committing a full multi-brand rollout to the new model.
Why Business Units Were the Enterprise Blocker
Enterprise marketing cloud organizations rarely serve a single brand targeting a single audience. A retail group with five brands, a financial services firm with distinct consumer and commercial lines, or a healthcare system with regional units operating under varying compliance regulations these are the typical scenarios for enterprise marketing clouds, not the exceptions. Within the marketing cloud engagement, each of these entities is assigned its own distinct business unit, complete with its own subscriber data, sending domains and IPs, automation and journey scopes, and user roles. While shared data can be intentionally transferred between business units via Enterprise 2.0 sharing, everything remains siloed by default.
Marketing Cloud Next, built on Salesforce Core and Data 360 (formerly Data Cloud), originated with a single-org, single-tenant model. This serves as an ideal default for mid-market customers managing a single brand. However, this model quickly falls short for large enterprise customers; their compliance teams may require that European subscriber data never mix with US-based sending infrastructure, or their distinct brand teams may need separate unsubscribe governance so that a complaint against one brand does not halt message delivery for another.
I have participated in numerous workshops where the primary reason for not choosing ‘Marketing Cloud Next’ was that its governance model did not align with the way the client’s organizational chart operated, not because the platform’s automation or AI capabilities were lacking (which was rarely the case). This release addresses precisely that shortcoming.
What the New BU Model Does and What It Doesn’t
The new model doesn’t recreate the Enterprise 2.0 business unit hierarchy wholesale. It partitions data and marketing assets across business units in a way that mirrors how Account Engagement handles multi-BU setups, rather than mirroring Marketing Cloud Engagement’s structure. Practically, that means you’re not getting an identical mental model if you’re migrating from Engagement; you’re getting an adapted one, and the mapping exercise between “how our BUs work today” and “how they’ll work in Next” needs to happen explicitly, not assumed.
A few things I’d walk through with a client at the design stage:
- Data partitioning boundaries. Confirm exactly what’s isolated per business unit versus what remains shared at the org level — subscriber data, consent records, and Data Cloud objects don’t necessarily all follow the same isolation rules, and that has direct compliance implications for regulated industries.
- User and permission scoping. Map who needs cross-BU visibility (typically a central marketing ops or CRM admin function) against who should be hard-scoped to a single BU (regional or brand marketing teams). Get this wrong, and you either lock out legitimate cross-brand reporting or you create a permissions model that fails an internal audit.
- Sending infrastructure and reputation. Verify whether sending domains, IP allocation, and deliverability reputation are managed per business unit the way they were in Engagement, or whether that’s still org-level in this release. This is not a cosmetic detail — a shared sending reputation across BUs means one brand’s poor list hygiene degrades deliverability for every other brand on the same infrastructure.
- Journey and automation scope. Determine whether journeys, automations, and audience segments built in one BU are naturally isolated from another, or whether cross-BU reference is possible and needs governance rules of its own.
None of this is a criticism of the feature. It’s the normal reality of a first-generation capability landing in a platform still maturing toward enterprise parity. The right move is to treat this release as “enterprise-capable,” not “enterprise-complete,” and design accordingly.
Migrating from Marketing Cloud Engagement: Don’t Replicate, Rationalize
If you’re advising a client currently on Marketing Cloud Engagement with an existing Enterprise 2.0 business unit structure, the temptation is to map BUs one-to-one into Next and call the discovery phase done. I’d push back on that every time. Engagement’s BU model reflects years of legacy decisions: BUs created for campaigns that no longer run, shared data extensions with no remembered purpose, and permission sets copied forward from a reorg three years ago. Migrating to Next is the natural time to rationalize that structure, not preserve it.
A cleaner approach:
- Run a BU inventory against actual current business need, not historical structure. Which BUs are active, which are dormant, and which exist purely because of a legacy sharing relationship that no longer applies.
- Separate “brand identity” boundaries from “operational” boundaries. Some clients split BUs by brand for governance reasons; others split by function (e.g., email vs SMS vs push) for operational reasons. Next’s partitioning model may handle these two motivations differently, and conflating them in your design will cause rework later.
- Plan consent and preference center consolidation early. If subscribers interact with multiple brands under one BU structure today, decide up front whether Next’s partitioning preserves that unified consent record or requires a redesign of your preference center architecture.
- Validate reporting and attribution needs before finalizing the BU boundary. Marketing ops teams that need cross-brand performance visibility will feel the impact of an over-partitioned structure immediately, usually in the first monthly reporting cycle after go-live.
I have often observed a common mistake in the initial stages of discussion: people view the creation of Business Units (BUs) merely as a technical partitioning task. In reality, it is primarily a matter of organizational design, with configuration being a secondary step. Before configuring any BU, bring together the client’s stakeholders, brand marketing leads, and the compliance and CRM operations teams.
What I’d Tell a Client Evaluating This Today
If ‘Business Units’ were the only obstacle preventing a client from adopting ‘Marketing Cloud Next,’ then that conversation can be revisited following this release. However, the mere existence of a feature is one thing, while its suitability for a client’s specific regulatory and operational needs is quite another; the decision to ‘go live’ should be based solely on the latter.
Before recommending a migration timeline, I’d want confirmed answers on: how granular the data isolation actually is for the client’s specific compliance obligations (GDPR data residency requirements look different from a simple brand-separation requirement), whether the sending infrastructure model meets their deliverability governance needs, and whether the current tooling around BU administration is mature enough for a large admin team to operate without constant workarounds. Early-release features in any platform tend to have gaps between “supported” and “battle-tested,” and enterprise clients rightly have low tolerance for finding those gaps in production.
The honest guidance right now: pilot this with a lower-risk business unit first, even if the client’s ultimate goal is a full multi-brand rollout. Validate the partitioning model against one real use case with real data volume before committing every brand’s send infrastructure to it.
Conclusion
In Marketing Cloud Next, the ‘Business Unit‘ aspect was not a minor shortcoming; rather, it was a critical requirement that often stalled major enterprise-level discussions at the discovery stage. While this release doesn’t necessarily make those conversations trivial, revisiting them could certainly prove beneficial. If you are considering Marketing Cloud Next for a multi-brand or multi-region organization, start with a limited pilot project based on your actual compliance and governance needs, rather than expecting feature parity with Marketing Cloud Engagement. Before migrating any subscriber records, map your existing Business Unit structure against actual operational requirements.
T C Kotteeswaran
T. C. Kotteeswaran is a Salesforce Marketing Cloud Tech Lead with over 9 years of experience delivering enterprise-scale marketing automation and customer engagement solutions on the Salesforce platform. He specialises in Salesforce Marketing Cloud Engagement, Marketing Cloud Advanced (Next), Data Cloud, Journey Builder, Automation Studio, AMPscript, SSJS, SQL, and Salesforce CRM integrations. Throughout his career, he has led technical teams, designed scalable solution architectures, and delivered complex implementations for enterprise clients across multiple industries. He is passionate about sharing practical insights, implementation best practices, and emerging Salesforce technologies to help organisations build secure, scalable, and high-performing digital marketing solutions.
