Why Enterprise Editorial Teams Outgrow All-in-One DXPs

A content lead at a company running six brands across four markets opens a ticket to change one line of escalation language, and it lands in an engineering sprint queue behind a release train. Two weeks later the language is still wrong, the campaign it was meant to support has shipped, and Legal is asking why the never-say list was never applied. This is the failure mode enterprise editorial teams hit inside an all-in-one DXP: authoring, presentation, personalization, and delivery are fused into one suite, so every editorial change waits on the monolith's release cadence and a UI nobody outside engineering can reshape.

Sanity is the Content Operating System for the AI era, the intelligent backend for companies building content operations at scale, and it splits those concerns apart on purpose. Schema lives in code, content lives in Content Lake, and editors work in a Studio that adapts to how the business is actually organized rather than the other way around.

This article reframes the DXP question. The suites that scored well for one brand shipping one website become the constraint the moment you run many brands, many markets, and many surfaces. We will look at where that ceiling shows up, and how a modeled, governed, single source of truth clears it.

The all-in-one bundle is an asset until you run more than one brand

An all-in-one DXP earns its keep in a specific situation: one brand, one primary website, one editorial team, and a marketing suite whose analytics, personalization, campaign, and DAM tooling all assume that shape. Inside that box, the tight coupling is a feature. Everything ships together because everything is the same thing.

The trouble is that enterprise editorial reality rarely stays that shape. A brand gets acquired. A new market opens with its own language, regulations, and seasonal calendar. A product line spins up a microsite, then an app, then an in-store screen, then a support agent that answers customer questions. Each of those is a surface that needs the same underlying facts, product descriptions, pricing rules, brand voice, and compliance boundaries, expressed differently. The bundle that made one website fast now asks every one of those surfaces to route through a single authoring UI and a single release cadence.

That is the moment the suite stops being an accelerator and becomes the governor on your throughput. You are not slow because your people are slow. You are slow because the architecture forces sequential work through a monolith that was designed for a simpler org chart. Legacy CMSes and DXPs stop at publishing a page; the multi-brand enterprise needs content to operate across every channel at once, and the bundle has no seam to let it. This is the structural reason editorial teams outgrow the box, and it maps directly to the first Sanity pillar, model your business, rather than modeling your business to fit the tool.

Model your business, not the vendor's fixed editorial UI

The first thing a growing editorial estate needs is a content model that reflects how the company is actually structured, brands, markets, product lines, and channels, and a place to author it that does not require an engineer for every change. In an all-in-one DXP, the schema is built and managed inside the platform, and the authoring experience is largely fixed. You adapt your workflows to the UI you were given. That is tolerable at one brand and increasingly expensive at ten.

Sanity inverts that. Schema is defined in code and source-controlled, so a content model change moves through the same review and versioning discipline as any other engineering artifact, and content lives in Content Lake, decoupled from the schema so you can evolve one without breaking the other. Editors, meanwhile, work in Sanity Studio, a fully customizable React application you shape to the team, not a screen the team bends around. Studio Workspaces let a single Studio serve many brands and markets, so a multi-brand estate is modeled in one place instead of stitched across separate instances.

The governance payoff is concrete. Role-based fields let Brand own voice, Product own the user-context rules, Support own escalation language, and Compliance own the never-say list. As the Sanity knowledge library puts it, splitting content into fields this way is not cosmetic, it is access control. None of those teams files a pull request. None waits for a deploy. The escalation-language ticket that started this article becomes a Studio edit by the person who owns escalation, not a sprint item behind a release train. Legacy CMSes make you work their way; a Content Operating System adapts to yours.

Governance you already trust, applied to content instead of code

Enterprise buyers do not adopt a new content backend to lose the controls their DXP gave them. Deep approval workflows, audit trails, and permission gating are genuine strengths of the incumbent suites, and any credible alternative has to meet that bar before it wins on anything else. The mistake is assuming those controls only exist when authoring, delivery, and governance are welded into one monolith.

Sanity ships the governance primitives an enterprise expects as first-class features of the content layer: drafts, scheduling, version history, permission gating, and audit trails, backed by Roles and Permissions, SSO, and Audit logs. Because content is structured and governed in the Studio, real-time collaboration, version history, scheduled publishing, and rollback come with it rather than being bolted on. The knowledge library frames the real choice cleanly: it is not content-loose versus code-rigorous, it is governed, with the right people able to edit and a test gate on the way out, versus a string only engineering can touch.

Content Releases are the mechanism that makes this operationally safe at scale. You stage and ship a batch of changes as a single unit and preview before you ship, the way you already stage a website. A market launch, a rebrand rollout, or a coordinated price change across brands moves as one reviewable release instead of a scatter of individual edits nobody can roll back together. This is the Automate pillar in service of governance: the release that ships a homepage change can ship a policy or voice change alongside it, atomically, with the audit trail intact. On compliance posture, Sanity holds SOC 2 Type II, is GDPR-aligned, offers regional hosting and data residency, and publishes its sub-processor list, the enumerable facts an RFP author actually needs.

One source of truth, power any surface

The defining tax of the all-in-one model at scale is duplication. When authoring is coupled to presentation, content tends to get re-entered, re-approved, and re-governed for each surface it appears on. The product description on the website, the app, the in-store screen, and the customer-facing agent drift apart because there is no single place they all read from. Every drift is a compliance risk and a support ticket waiting to happen.

The Power anything pillar answers this with a single source of truth. You update once, and web, apps, internal co-work tools, and customer agents stay in sync, because they all read the same structured content from Content Lake over its APIs. Content is data, not a page, so a channel that did not exist when you authored the content can consume it later without a re-author. Sanity positions this explicitly as Content Lake plus a Content OS for AI: structured content as fuel for agents and RAG as well as for the web, with a strong Next.js story through next-sanity and an official partnership with Vercel.

This is where the AI question enters as a scale and governance vector rather than a headline. When a customer-facing agent needs to find something in your data, GROQ hybrid retrieval blends structured predicate filtering, keyword scoring with text::query() and boost(), and semantic ranking with text::semanticSimilarity() in a single query ordered by _score. Because retrieval is wired into the content backend, re-indexing on publish, price change, or deletion happens by default; freshness stops being a permanent line item on your roadmap. The same single source of truth that keeps four human-facing channels consistent is what an agent grounds against, governed by the same permissions.

Scale output, not headcount

The quiet economics of the all-in-one DXP is that its throughput scales with people. Because so much editorial work routes through engineering, a fixed UI, and a monolithic release cadence, the way you ship more content across more brands is to hire more coordinators, more developers, and more agency hours. The bundle that was supposed to make you efficient ends up making growth a hiring plan.

Sanity's fifth differentiator is aimed exactly here: rigid CMSes force you to scale people, while a Content Operating System scales output. Functions and the App SDK let you automate the enterprise workflows that would otherwise be manual, translation handoff to Phrase or Smartling, moderation, compliance checks, and content enrichment, running as code anywhere you can run code rather than as clicks in a fixed console. Because schema and workflow logic are not UI-bound, a new market or a new brand is a modeling and configuration exercise, not a fresh implementation project.

The build-versus-buy instinct that enterprise teams feel toward their DXP is real and worth naming honestly. Walter Colindres at Jack in the Box put the discomfort plainly: two hundred thousand dollars going out the door does not feel comfortable for something the team could ultimately build, own, and operate for less over time. The point is not that DXPs are overpriced by definition; it is that a modern content operation should let the whole organization contribute and own its content, the way Vipps wanted the whole company, not just engineers, to own content that had traditionally lived in code. When Nearform stored an agent's system prompt in a Sanity document, editors tuned the voice with no code changes. That is output scaling without headcount scaling.

Meeting the incumbents where they actually win

None of this means the legacy DXPs are dead or that a replatform is free. AEM, Sitecore, and Optimizely have large installed bases for good reasons: deep and configurable approval workflows, mature partner and systems-integrator ecosystems that can staff a global rollout, and tight native integration with their own marketing suites, analytics, personalization, campaign, and DAM tooling that a composable stack assembles rather than inherits. If your organization is one brand deeply invested in one vendor's marketing suite and your editorial estate is not fragmenting, the bundle may still be the right answer. Credibility requires saying so.

The honest comparison is not feature-for-feature; it is axis-by-axis on the dimensions a multi-brand enterprise actually feels. Where the incumbent wins is depth within a single integrated suite. Where the composable model wins is the seam: source-controlled schema you can evolve, a Studio you can reshape per brand and market, releases you can stage and roll back as units, and a single source of truth every surface, including AI agents, reads from without re-authoring.

The practical migration reality also matters. Because Sanity decouples schema from content and exposes everything over APIs, an enterprise can move surface by surface, standing up a new channel on Content Lake while the legacy system still serves others, rather than committing to a multi-year big-bang reimplementation. The partner network exists for exactly the large rollouts that the incumbents' SI ecosystems handle today. You meet buyers where they are, on the axes their DXP scored on, and show which of those axes a Content Operating System scores higher.