Third and final part of the content-layer trilogy. The CMS made structured content manageable. The DAM made digital assets governable. The DXP promised to make the experience built from both of them coherent.
There is a useful way to recognise an unstable software category. Ask five vendors what belongs inside it, and if you receive five different architecture diagrams, you are probably looking at a category built around an ambition rather than a settled product boundary. DXP is one of those categories. Digital Experience Platform sounds precise, and each word appears to narrow the definition, but in practice the last word does most of the work. Depending on the vendor, a DXP can include content management, digital asset management, personalisation, experimentation, analytics, customer data, commerce, search, portals, forms, journey orchestration, campaign management and now AI agents. That does not make the category meaningless. It means the category was created to describe a genuine architectural problem that no single product boundary could contain.
By the middle of the 2010s the website was no longer just a collection of pages. It was an application, a commerce interface, a service channel, a customer portal and an authenticated part of a wider journey, and content alone was not enough, because the experience also required customer context, integration, transactions, personalisation and continuous optimisation. The CMS could manage what appeared on the screen, but it could not necessarily coordinate everything required to decide what that screen should become for a specific customer in a specific moment. DXP was the industry’s attempt to name the layer above that complexity. Then vendors discovered that almost every adjacent capability could be described as part of digital experience, so the category expanded, and expanded, until DXP sometimes became less a product definition than a claim on the whole stack.
What it actually solved
The original DXP problem was fragmented digital delivery. An organisation might have a CMS for the public website, a portal platform for authenticated users, a commerce engine for transactions, a separate personalisation tool, analytics tags, search, identity services and custom integrations into CRM and back-office systems. From the customer’s perspective these were all one experience, but from the architecture’s perspective they were separate systems with separate data models, release cycles, interfaces and owners, and the gap between those two realities created the need for a broader platform concept.
A DXP promised to coordinate the composition, management, delivery and optimisation of digital experiences across channels, and Gartner’s current definition still reflects that ambition, describing a cohesive set of integrated technologies that orchestrates multiple applications through APIs to create and present personalised experiences. The important word there is not digital but cohesive. The DXP was supposed to reduce the junctions between the capabilities required to run a modern digital estate: content and asset management, page and application composition, customer and account context, authentication and permissions, personalisation and decisioning, commerce and transactions, experimentation and optimisation, integration with enterprise systems, and delivery across websites, applications, portals and other interfaces.
The first Gartner Magic Quadrant for Digital Experience Platforms appeared in 2018, replacing the earlier Horizontal Portals category, and that lineage is revealing. DXP did not emerge only from marketing technology, it also emerged from enterprise portals, web content management and the need to build connected digital services for customers, partners and employees, so the category inherited several different architectural traditions at once. Portal vendors started from authenticated access and integration, CMS vendors started from content and presentation, commerce vendors started from product discovery and transaction, and marketing suites started from customer data, personalisation and campaign execution. They all arrived at DXP from different directions, which is why the category solved a real problem without ever producing one stable product shape.
The market that shaped it
The DXP market was shaped by the enterprise desire for coherence. Large organisations did not want customers to experience the boundaries between departments and systems, they wanted a consistent journey across public content, logged-in services, commerce, support and communication, and they wanted fewer implementation junctions, because every integration between CMS, DAM, commerce, analytics, personalisation and customer data created cost, every separate user interface created training overhead, and every independent data model created another place where definitions could diverge. The suite proposition was therefore compelling: buy an integrated platform from one strategic vendor, and the pieces will work together more naturally than a collection assembled independently.
Sometimes they did. Sometimes the integration was primarily commercial, where a vendor acquired several products, added them to the same contract and presented the collection as a platform, while shared identity, workflow, data and administration arrived later, partially or not at all. The market learned that product proximity is not architectural coherence, and that two applications can appear next to each other in a navigation menu and still operate as separate systems.
At the same time the number of digital touchpoints continued to increase. Responsive websites became mobile applications, commerce became embedded in content, customer portals became service hubs, and personalisation moved from page-level targeting toward real-time decisioning, so teams needed to release faster and connect more specialised capabilities. The all-in-one DXP began to feel both attractive and restrictive, because it reduced some integration burden while concentrating roadmap dependency and switching cost, and an organisation could gain coherence while accepting the vendor’s data model, deployment model and view of how experience should be assembled. That tension produced the next version of the category, the composable DXP.
How vendors changed the meaning
The first DXP vendors expanded outward from their strongest product. A CMS vendor added personalisation, analytics and assets, a portal vendor added content management and marketing capabilities, a commerce vendor added experience composition, and a marketing cloud connected customer data, content, campaigns and optimisation. The centre of gravity differed, but the positioning converged, because each vendor wanted to become the place where the digital experience was assembled and governed. That made DXP one of the broadest categories in enterprise software, and it created a predictable sales pattern, in which any capability touching the customer-facing experience could be pulled inside the definition. Search became part of DXP, DAM became part of DXP, CDP became part of DXP, experimentation became part of DXP, commerce became part of DXP, and journey orchestration sometimes became part of DXP too. The category did not merely expand, it tried to absorb the architecture around it.
The composable movement was partly a reaction to that expansion. MACH principles, microservices-based, API-first, cloud-native SaaS and headless, offered a different model in which organisations could assemble specialised capabilities and connect them through APIs instead of purchasing one large suite, and the phrase composable DXP captured the compromise. The organisation still wanted a coherent digital experience platform, but the platform no longer had to be one vendor’s product. This is an important shift in meaning, because a suite DXP is something a vendor sells while a composable DXP is something an organisation architects and operates. The difference is not only technical. In a suite model the vendor owns more of the integration roadmap, shared services and upgrade path, and the organisation trades some independence for product-level cohesion. In a composable model the organisation owns the control plane between components, gaining flexibility and reversibility but having to fund integration, observability, design-system consistency, shared governance and product management across the whole estate. Composable does not eliminate platform responsibility. It transfers it.
The newest expansion is agentic. Forrester’s 2025 DXP evaluation described agentic orchestration as a force reshaping the category, and vendors are embedding agents that help create experiences, recommend changes, assemble content, personalise interfaces and coordinate work across the platform. This gives DXP a new reason to exist, because an agent can potentially hide some of the complexity between content, assets, data, experimentation and delivery, and a marketer may describe an outcome rather than operating each underlying tool separately. But the agent does not remove the junctions, it acts through them. If content identifiers do not match asset identifiers, if customer context is inconsistent, if consent rules differ by channel or if the commerce API exposes stale availability, the agent will not create coherence, it will automate the inconsistency. The clearest current example of where this is heading is Salesforce’s 2026 agreement to acquire the headless content platform Contentful, reportedly for somewhere between one and one and a half billion dollars, well below its 2021 valuation of around three billion. A CRM company did not buy a content platform because it wanted to be in publishing. It bought a governed content layer so that Agentforce would have approved, structured content to assemble from at runtime, which is the agentic DXP thesis expressed as an acquisition. The DXP is becoming an orchestration surface for agents, and that makes the underlying architecture more important, not less.
What it means architecturally today
A DXP should not be treated as a box in the architecture diagram. It is better understood as a capability model and a control-plane decision, because the practical question is not simply whether the organisation needs a DXP. Most organisations with a significant digital estate already have the capabilities associated with one, even if they are spread across several products, so the real questions are which capabilities need to behave as one platform, who owns the integration between them, where the experience is assembled, where customer context enters the decision, which layer governs content, assets, identity, consent and experimentation, and what must be replaceable versus what is allowed to become strategic infrastructure.
A useful DXP architecture normally makes at least seven ownership decisions explicit. It decides content ownership, which CMS or content platform governs structured content, localisation and editorial workflow. It decides asset ownership, which DAM governs approved media, metadata, rights and transformations. It decides experience composition, where pages, components, interfaces and application states are assembled. It decides customer context, which CRM, CDP or data platform provides identity, profile and behavioural information. It decides decisioning and personalisation, which system selects offers, content variants or next-best actions. It decides runtime delivery, which front-end, edge, commerce and delivery services produce the actual experience. And it decides measurement and optimisation, where experiments are defined, outcomes measured and learning fed back into the experience.
A suite can answer many of these questions with one vendor, and that may be the right answer, but it is not automatically one architecture. A composable stack can answer them with several specialised platforms, and that may also be the right answer, but it is not automatically coherent. The distinction I use is simple: co-location is not cohesion, and composability is not governance. A suite fails when its products are implemented as separate modules with duplicated models, fragmented teams and no shared operating contract, and a composable architecture fails when it becomes a collection of preferred tools with no product team responsible for the experience across them. In both cases the customer experiences the junctions even when the architecture diagram hides them. This is where DXP selection often starts too early, because teams compare vendors before deciding what they want the platform to own. They ask whether a product includes CMS, DAM, personalisation or analytics, but not where the authoritative model for each capability should live; they score connectors without deciding who will operate them; and they celebrate flexibility without pricing the organisational capacity required to sustain it. The better evaluation question is which parts of digital experience should share one control plane and which parts must remain independently governed, because that answer determines whether the target architecture should lean toward a suite, a composable platform or a deliberate hybrid.
What it gets confused with
DXP overlaps with almost every category in this trilogy and several outside it. It is not a CMS, because a CMS manages content while a DXP coordinates a broader set of capabilities required to create, deliver and optimise an experience; many products marketed as DXPs remain strongest in CMS, which is not a criticism, but the distinction should be visible. It is not a DAM, because the DAM governs assets while the DXP may consume those assets and include DAM capabilities without asset governance being more than one part of the experience lifecycle. It is not a CEP, because a CEP listens to customer signals, applies decisioning and orchestrates interactions across channels while a DXP is usually more focused on the composition and delivery of digital properties such as web, app, portal and commerce experiences; the categories overlap around personalisation and real-time interaction, but their operating centres are different. It is not a CDP, because a CDP creates and activates a persistent customer profile while a DXP may use that profile to personalise the experience, and when a DXP includes customer-data capabilities the question is whether they meet enterprise identity and governance requirements or only the needs of the experience layer. It is not a marketing cloud, because marketing clouds usually combine data, campaigns, analytics, advertising and engagement capabilities while a DXP may sit inside one, overlap with one or be positioned as the experience-delivery part of one, so the labels reflect vendor packaging more than universal architecture. And it is not a front-end framework, because the front end renders the experience while the DXP provides some of the services, content, context and governance behind it, and even a modern composable architecture that makes the front-end layer highly visible still depends on the systems underneath.
The easiest way to hold these distinctions is by the question each layer answers. The CMS asks what content exists and how it is governed. The DAM asks which assets exist and where they may be used. The CDP asks who this customer is and what we know about them. The CEP asks what interaction should happen next. And the DXP asks how these capabilities become one digital experience. That is a valid question. It is not proof that one product should answer all of it.
Does it still matter
DXP still matters, but it is more useful as an architectural question than as a procurement answer. The need behind the category has not gone away, because customers still expect coherent experiences across public sites, authenticated services, commerce, applications and communications, organisations still need content, assets, data, decisioning and delivery to work together, and the cost of fragmentation remains real. What has changed is the assumption that coherence must come from one integrated suite. For some organisations suite gravity is appropriate, since existing investment, governance requirements, skills and the need for common services can make a broad DXP the most operable choice. For others a composable approach is stronger, because a mature digital product organisation may prefer specialised services, API-level control and the ability to replace components without moving the whole estate. Most enterprises will operate somewhere between the two, with a dominant platform, several independent strategic systems and an integration layer that determines whether the combination behaves coherently.
The agentic shift will make this architecture less visible to users. It will not make it less important. An agent may become the interface through which marketers assemble experiences, another agent may optimise the journey, and a third may retrieve content and assets, so the user may no longer know which underlying product performed each operation. But someone still needs to decide which system is authoritative, what the agent can read, what it can change, which rules are shared across the platform, how every action is audited, and what happens when two systems believe they own the same decision. This is why I would not begin a DXP evaluation by asking which vendor offers the broadest suite. I would begin by asking what kind of coherence the organisation is actually prepared to operate. The DXP acronym emerged because the CMS was no longer enough, it expanded because digital experience touched almost every layer of the stack, and it survived the composable reaction because the need for coherence survived too. The category’s mistake was not being too ambitious. The mistake was allowing ambition to sound like a product boundary.
A DXP can provide the platform, but only architecture and operating discipline can provide the coherence, so treat it as a control-plane decision about what should share one plane, never as a suite you can buy your way to coherence with.
Sources
Gartner
- Digital Experience Platforms (DXP defined as integrated technologies for composing, managing, delivering and optimising personalised digital experiences across channels.) · Gartner Retires the Magic Quadrant for Web Content Management (The 2020 retirement of the WCM Magic Quadrant as demand shifted to the broader DXP scope.)
MarTech
- Gartner releases its first Magic Quadrant report on Digital Experience Platforms (The 2018 introduction of the DXP Magic Quadrant and its replacement of the Horizontal Portals category.)
Liferay
- Why Portals Are Becoming Digital Experience Platforms (The portal lineage behind the first DXP market definition.)
Acquia
- What is a composable DXP? (The distinction between a modular, API-first DXP and an all-in-one suite.)
MACH Alliance
- The MACH Manifesto (The microservices-based, API-first, cloud-native SaaS and headless principles used in many composable DXP architectures.)
Optimizely
- Digital Experience Platform (A vendor view of DXP spanning content, personalisation, experimentation and commerce.)
Forrester
- Announcing The Forrester Wave: Digital Experience Platforms, Q4 2025 (Agentic orchestration as a force reshaping the DXP market.)
Salesforce
- Salesforce Signs Definitive Agreement to Acquire Contentful (A current example of CRM, customer data, agents and composable content converging inside a broader experience-platform strategy.)
