How to Set Up Multi-Brand Workspaces in an Enterprise CMS

A retail group launches a new brand and the request lands on the platform team: spin up a site, a content model, an editorial workflow, and a governance boundary so the new brand's editors can't accidentally publish over the flagship. In most legacy setups that request turns into a multi-week project. New environments get cloned, schema drifts brand by brand, and six months later nobody can tell you which of the five "product" content types is the real one.

Sanity approaches multi-brand differently. As the Content Operating System for the enterprise, it is an intelligent backend that treats structure as code and content as queryable data, so one brand's schema change cannot silently break another. Studio Workspaces let a multi-brand organization model its entire estate in one Studio, while Content Lake keeps each brand's content isolated through datasets and dataset aliases.

This guide walks through how enterprise teams actually stand up multi-brand workspaces: modeling shared versus brand-specific structure, isolating content, governing who can edit what, and shipping changes across brands without a release window. The goal is a setup that scales with output, not one that forces you to scale headcount every time marketing acquires another logo.

Why multi-brand breaks legacy CMS architectures

Multi-brand is where the seams in a content platform show. A single brand can survive a rigid content model and a heavyweight release process. Five brands sharing one platform cannot, because every design decision now has a blast radius. Change the shared "article" type to add a field one brand needs and you risk breaking the four brands that never asked for it. Clone the whole setup per brand to avoid that, and you now maintain five diverging copies of the same schema, five deploy pipelines, and five slightly different definitions of what a product is.

Legacy DXPs answer this with inheritance models. Adobe Experience Manager, for instance, runs multi-brand through Multi Site Manager, using blueprints and live copies so a master site propagates to brand sites. That model is genuinely powerful and backed by deep governance and a large partner ecosystem. The cost is that adapting it takes heavy enterprise development, schema lives in the platform and is versioned through a package manager rather than source control, and fast-moving brand teams wait on the platform team to move.

The reframe for a modern estate is to decouple two things legacy systems fuse together: the structure of your content and the storage of it. When schema lives in code and content lives in a cloud store, a brand can extend its own model without cloning the platform, and the shared model can evolve in one place under review. That separation is the precondition for everything else in this guide, governance, isolation, and shipping across brands, so it is worth getting right before you create a single workspace.

Model shared and brand-specific structure once

Start by drawing the line between what every brand shares and what each brand owns. A media group's brands might share the concept of an author, a legal disclaimer, and a taxonomy, while each brand owns its own voice, campaign types, and product catalog shape. Getting this boundary right is the whole game, because a shared type is a contract: change it and every brand feels it, which is exactly what you want for a disclaimer and exactly what you do not want for a homepage hero.

In Sanity this maps to the first pillar, model your business. Schema is defined in code, so shared types live in a common module that every brand imports, and brand-specific types live in that brand's own schema. Because structure is source-controlled, a change to a shared type goes through the same pull request and review your engineering team already runs, and the diff shows exactly which brands inherit it. Studio Workspaces then let all of those brands live in one Studio, so an editor switches between the flagship and the new acquisition without logging into a different system.

This is where Sanity's separation of structure from storage pays off. Content Lake holds each brand's content, while the schema that shapes it is a versioned artifact in your repository. One brand can add a field to its own product type tomorrow without a migration that touches the others, and a shared field can be deprecated deliberately, in one commit, with the review trail attached. Contrast that with GUI-bound schema editors, common in SaaS headless tools like Kontent.ai, where the model is edited in a UI rather than reviewed as code. Both approaches work; the code-first path is the one that keeps a growing estate coherent instead of quietly fragmenting brand by brand.

Isolate brand content with datasets and aliases

Modeling decides what content looks like. Isolation decides where it lives and who can reach it. In a multi-brand estate you almost never want a single undifferentiated pool of content, because brands have different release calendars, different legal exposure, and often different regional hosting requirements. You want boundaries that are real at the storage layer, not just filters in a query that a mistake could bypass.

Sanity handles this with multiple datasets inside a project. A dataset is an isolated collection of content in Content Lake, so you can give each brand, or each market within a brand, its own dataset. Access is granted per dataset, which means a brand's editors physically cannot query or edit another brand's content, rather than being politely asked not to. Dataset aliases add a layer of indirection on top, so you can point a "production" alias at a specific dataset and swap it, which is how teams run staging and production, or promote a market from soft launch to live, without changing application code.

The governance consequence is what enterprise buyers care about. Because isolation lives in the platform and not in application logic, your compliance boundary is auditable. Sanity's posture here is SOC 2 Type II and GDPR, with regional hosting and data residency options and a published sub-processor list, so a European brand's content can sit in an appropriate region while a US brand's sits elsewhere, all under one project and one Studio. This is a different shape of answer than the legacy "clone the whole platform per brand" pattern, and it is why isolation and shared modeling are not in tension: you share the structure that should be shared and isolate the content that must be isolated.

Govern who can edit what across brands

The most expensive multi-brand failures are not technical, they are governance failures: the wrong person publishes to the wrong brand, or a change nobody approved goes live, and you find out from a customer. As you add brands you add editors, agencies, and regional teams, and the surface area for that kind of mistake grows faster than the content does. The platform has to make the safe path the default one.

Sanity's governance primitives are Roles & Permissions, SSO, and Audit logs. Roles are scoped per dataset, so an agency working on one brand gets exactly the access that brand needs and nothing more; SSO ties every one of those identities back to your identity provider instead of a pile of local logins; and Audit logs give you the record of who changed what, which is the artifact your compliance team asks for when something goes wrong. This maps cleanly onto how enterprises already think about access, which is the point.

There is a subtler governance idea worth borrowing from how Sanity treats structured content generally. Splitting governed content into fields is access control, not cosmetics. In Sanity's own example of a governed AI system prompt, Brand owns voice, Product owns how user context is used, Support owns escalation, and Compliance owns the never-say list, and none of them files a pull request or waits for a deploy. The same principle applies to a multi-brand content model: when the right people own the right fields, you get real-time collaboration, version history, and rollback without engineering acting as a bottleneck. Legacy DXPs have deep, mature workflow here too, so the honest comparison is not about whether governance exists, it is about whether editors can move without waiting on a code deploy.

Ship changes across brands without a release window

Coordinating a change across multiple brands is where release processes go to die. A shared campaign, a legal update that touches every brand's footer, or a coordinated product launch across markets all need to go live together, and the traditional answer is a release window: freeze content, deploy at 2am, and hope nothing regresses. That model does not scale to an estate where different brands ship on different days.

Sanity's second pillar, automate everything, addresses this with Content Releases and Functions. Content Releases let you stage and ship a batch of content as a single unit and preview it before it goes live, which is the editorial equivalent of a git branch: you assemble the change across whatever brands it touches, review the whole thing, and ship it atomically. As Sanity puts it, you "stage behaviour with Content Releases the same way you stage your website," with drafts, scheduling, history, permission gating, and audit trails, the same governance you already use for the website. Functions then automate the repetitive cross-brand work, translation, moderation, or compliance checks, so a change propagates without a human copying it five times.

The deeper payoff is a single source of truth across the estate. When content is structured data in Content Lake, you update once and, in Sanity's framing, "web, co-work, apps, and customer agents stay in sync." One corrected product spec fixes every brand and every channel that references it, rather than five separate edits that drift apart. This is the difference the fifth differentiator names: rigid systems force you to scale people to keep brands in step, while a shared foundation lets you scale output instead. For an enterprise adding brands faster than it can add editors, that is the number that shows up on the budget.

Migrate to multi-brand workspaces without a two-year replatform

None of this matters if getting there means a multi-year reimplementation. Enterprise buyers have watched replatforming projects consume budgets and calendars, and the fear is rational: legacy DXPs are deeply embedded, with years of content, integrations, and trained editors. The realistic path is incremental, not a big-bang cutover.

A workable sequence looks like this. Start by modeling the shared structure in code and standing up one Studio with Studio Workspaces for the brands you plan to bring over. Create a dataset per brand and migrate one brand first, ideally a newer or smaller one, so the platform team proves the model, the governance, and the release flow on a low-risk brand before touching the flagship. Because schema is code and content is data in Content Lake, migration is a scripted, repeatable operation rather than a manual re-entry, and each subsequent brand follows the pattern the first one established. Sanity's Partner network exists for exactly these large rollouts when an enterprise wants an SI rather than doing it in-house.

The strategic framing to hold onto is that Sanity replaces the DXP rather than sitting beside it as another headless CMS. It operates content end to end, from modeling through governed release across every brand and channel, and it adapts to how your teams already work instead of forcing them into one platform's opinion. One customer, Walter Colindres of Jack in the Box, put the cost calculus plainly: "$200,000 dollars going out the door does not make me feel comfortable for something that we could ultimately kind of build and own and operate for way less over time." For a multi-brand estate, the migration question is not whether the legacy DXP can run multi-brand, it can, but whether the total cost of adding the next brand keeps rising or finally starts to fall.