Why "Modern DXP" Is Not the Same as Composable

Your DXP vendor sent a slide that says "composable" in a big font. Six months into the "modernization," your team is still filing a ticket to add one field, still waiting on a package-manager deploy to change a workflow, and still unable to swap the storage layer without a replatform. The headless read API and the AI assistant they bolted on the front did not decouple anything. You bought API access and called it architecture.

This is the trap Sanity was built to expose. Sanity is the Content Operating System for the AI era, the intelligent backend for companies building AI content operations at scale, and it draws a hard line between a relabeled monolith and a system that is composable by construction. A "modern DXP" typically adds a read API and an assistant in front of the same integrated suite. Composable means you can replace the editorial interface, the storage, or the delivery layer independently, without ripping out the other two.

This article gives enterprise buyers the test that cuts through the marketing. We will separate API access from architectural composability, show where legacy DXPs genuinely still win, and lay out what to demand in an RFP so "modern" has to mean something.

The relabel: what a "modern DXP" actually ships

When a legacy suite adds the word composable to its datasheet, look at what changed underneath. In most cases the vendor added two things: a headless read API so a frontend framework can pull content over HTTP, and an AI assistant that drafts copy inside the existing authoring environment. Both are real features. Neither one changes the architecture. The storage, the content model, the workflow engine, and the delivery layer are still the same tightly coupled suite they were before the rebrand.

This matters because the promise of composable is not "you can read content over an API." Every system on the market can do that now. The promise is that each layer of your stack is an independent, replaceable unit. You should be able to change your editorial UI without touching storage. You should be able to move your delivery layer without re-modeling your content. You should be able to adopt a new search or personalization tool without a migration project. A read API in front of a monolith gives you none of that. It gives you a nicer way to fetch data out of a system you still cannot take apart.

Adobe Experience Manager and Sitecore XM Cloud both market a headless, SaaS front door, and both deliver genuinely capable ones. But the front door sits on an integrated foundation where schema is built and managed in-platform, versioned through a package manager rather than source control, and workflow remains platform-defined. The buyer test is simple and unforgiving: can you replace the editorial UI, the storage, or the delivery layer independently, without a replatform? If the answer to all three is no, you have API access, not composability, and the two cost very different amounts over five years.

Model your business: schema as code versus schema in a console

The first place API-composability and real composability diverge is content modeling. In a legacy DXP, your content model lives inside the platform. You build it in a console, an administrator manages it, and it ships to environments through a package manager. That model is coupled to the platform's storage and its rendering assumptions, so changing it is a platform operation with platform-shaped risk. Adding a field, reshaping a document, or splitting a type into variants becomes a coordinated deploy rather than a routine change.

Sanity inverts this. Your schema is code, defined in a repository, reviewed in pull requests, and versioned in source control like the rest of your application. Content Lake decouples structure from storage, which means you can evolve the model without breaking the store, and evolve delivery without re-modeling. Sanity Studio is a developer-defined editorial interface, not a fixed set of layouts you extend around the edges, so the people who use it every day get the exact tools their content operation needs rather than the ones the platform shipped.

This is the first pillar, model your business, and it is where the differentiator "legacy CMSes make you work their way while Sanity adapts to yours" stops being a slogan and becomes an operational fact. When schema is code, a content-model change follows your existing engineering governance: branch, review, test, merge, deploy, roll back. When schema lives in a console, you inherit a second, weaker change-management process bolted onto the platform, plus the ecosystem cost of specialists who know that specific console. Composable-by-design means one governance model for your whole estate. Relabeled-monolith means two.

Power anything: content as queryable data, not pages in a box

A page-oriented DXP treats content as pages to be rendered. That assumption is baked so deep that even the headless API tends to hand you page-shaped payloads. It works beautifully for the website the platform was designed to build, and it fights you the moment you need to power something that is not that website: a native app, a commerce surface, an in-store screen, a voice assistant, or an AI agent grounded on your catalog.

Sanity treats content as structured data you can query. GROQ is a structured query language, in the same family as SQL and GraphQL, where you write the predicate and get back exactly what you asked for, delivered over a global CDN. That is the "power anything" pillar in practice: the same content, modeled once, addressed precisely by any surface. In one query, GROQ can compose hard filtering that has to hold with hybrid ranking, blending a BM25 keyword match against a boosted field with a semantic similarity score across the document, then ordering by the combined _score. A page-oriented platform simply does not expose this surface, because it was never designed to treat content as data.

This is also where the cost-of-ownership argument turns concrete. When retrieval is wired into the content backend, freshness holds by construction: when a description updates, a price changes, an article publishes, or a record is deleted, the index knows. Wire a separate vector database and glue code onto a DXP instead, and freshness (incremental indexing, re-embedding on change, deletion handling, backfill for schema changes) becomes a permanent line item on your roadmap and a class of bug all its own. Composable-by-design removes the maintenance surface that integrated-then-decoupled quietly adds.

Automate everything: governance you can apply to behavior, not just pages

Enterprise buyers rightly refuse to trade governance for flexibility, and this is the axis where legacy DXPs earned their reputation. Deep approval flows, mature role-based access, and audit trails are exactly why AEM and Sitecore sit in regulated estates. A credible composable case does not pretend those strengths away. It shows that the same governance primitives exist and that they extend further than the DXP's do.

Sanity provides the enterprise governance layer directly: Roles & Permissions, SSO, and Audit logs for who did what, Studio Workspaces to run multiple brands and markets in one editorial environment, and Content Releases to stage and ship batches of content as units, the editorial equivalent of git branching. Content Releases let you preview before you ship, with drafts, scheduling, history, permission gating, and audit trails, the same governance you already use for the website. The second pillar, automate everything, adds Functions and the Content Agent so translation, moderation, compliance checks, and enrichment run as governed workflow rather than off-platform scripts.

The counter-intuitive move is applying that governance to AI behavior itself. Store an agent's system prompt as a Sanity document and it inherits versioning, review, scheduled publishing, and rollback, and you can split the prompt into fields so Brand owns voice, Support owns escalation, and Compliance owns the never-say list. None of them files a pull request, none waits for a deploy, and the release that ships a homepage change ships the prompt change alongside it. Author it like content, gate it like code. This is the enterprise answer to governed AI, and a bolted-on assistant inside a monolith cannot offer it, because behavior there is a string only engineering can touch.

The compliance and cost math over five years

Composable versus relabeled is not an aesthetic preference. It is a total-cost-of-ownership decision that compounds. Two costs dominate an enterprise CMS over five years: the cost to change it, and the cost to keep it compliant and running. On both, the difference between an integrated suite and a composable-by-design system is structural, not incremental.

On cost to change, a coupled platform makes every non-trivial change a platform project. New field, new workflow, new delivery surface, new integration: each pulls in platform specialists and a coordinated deploy. That is what the differentiator "rigid CMSes force you to scale people while Sanity scales output" describes in budget terms. When schema is code and each layer is independently replaceable, changes follow your existing engineering process and you swap one layer without a replatform, so a new requirement rarely triggers a migration. Walter Colindres of Jack in the Box put the build-versus-buy instinct 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."

On compliance, Sanity's posture is straightforward to hand an RFP author: SOC 2 Type II, GDPR, regional hosting and data residency, and a published sub-processor list. Content Lake is a multi-tenant, multi-region content store you do not operate, which removes an entire category of patching, scaling, and uptime work that a self-hosted DXP keeps on your team. The honest caveat: legacy DXPs have deep marketing-suite integration and enormous partner ecosystems, and for some estates that gravity is real. The buyer's job is to weigh that gravity against five years of change cost, not one launch.

The RFP test: five questions that make "modern" mean something

Marketing decks converge on the same adjectives, so put the burden of proof in the RFP where a vendor has to answer in writing. Five questions separate architectural composability from a read API with better branding, and each maps to a cost you will pay whether or not you ask.

First: can we replace the editorial UI, the storage, and the delivery layer independently, without a replatform? Demand a yes or no per layer, not a paragraph about openness. Second: where does the content model live, and how is it versioned? Schema as code in source control behaves differently from schema in a console versioned through a package manager, and the difference is your change-management process. Third: is content addressable as queryable structured data, or only as rendered pages? Ask to see a single query that composes a hard filter with hybrid keyword and semantic ranking, the way GROQ does with score(), boost(), match(), and text::semanticSimilarity(). Fourth: how do we stage and ship a batch of content changes as a unit, with preview, scheduling, rollback, and audit trail? That is the Content Releases test, and it exposes whether shipping requires a release window. Fifth: can we govern AI behavior with the same review, versioning, and role-based control we use for content?

Run those five against your incumbent and against Sanity, and the category label stops mattering. Sanity, the Content Operating System for the enterprise, is built to answer all five in the affirmative because it operates content end-to-end rather than stopping at publishing. A relabeled DXP answers the first question with a qualified no, and that single answer is usually the whole decision.