DXP (Digital Experience Platform)

A DXP, or Digital Experience Platform, is a suite that combines content management with a set of adjacent tools in one integrated product. It wraps a CMS together with capabilities such as personalisation, marketing automation, campaign management, analytics, digital asset management and sometimes commerce, sold and run as a single platform. Adobe Experience Manager, Sitecore, Optimizely and Acquia are among the products marketed in this category. Gartner’s definition, quoted in Adobe’s own announcement of its 2020 Magic Quadrant placement, describes “an integrated set of technologies, based on a common platform, that provides a broad range of audiences with consistent, secure and personalized access to information and applications across many digital touchpoints”.

What is in the bundle, capability by capability

The contents differ by vendor, and every suite draws its own module boundaries. The pattern below holds across the category. Each capability carries a different obligation depending on where it comes from, which is what the final column records.

Capability	In a DXP suite	In a headless CMS	What each asks of you
Content management	The core module: authoring, workflow, versioning, publishing, multi-site and multi-locale handling, with templating and page delivery included	The same core, exposed over an API, with the presentation layer supplied separately	Suite: page structure follows the vendor’s templating model, and front-end work runs through it. Headless: you build, host and maintain the front end
Personalisation	Usually present, and among the capabilities most likely to sit in a higher edition or a companion product. Rule-based targeting on content is often in the base tier; behavioural profiling generally is not	Absent. Targeting logic sits in the front end or in a separate decisioning service	Suite: marketers configure rules in the same interface as content, and those rules live in vendor configuration. Headless: someone decides where profile data sits and what makes the decision
Campaign orchestration	Email, sequences and multi-step automation, generally licensed as a named product in the vendor’s catalogue	Absent. An email or marketing automation platform is integrated	Suite: the value depends on customer data reaching the same vendor’s store. Separate tool: an integration and an agreed identity key
Analytics	Reporting on content and campaign performance, drawn from the vendor’s own event store and tied to its delivery tier	Absent. A web analytics product is connected to the front end	Suite: reporting reaches as far as the vendor’s own event store, so a surface outside the suite is counted only once it is wired into it. Independent: covers every surface and needs its own instrumentation
Commerce	Varies most across the category. Sitecore’s catalogue carries OrderCloud and Experience Commerce, Optimizely’s carries Configured Commerce, and Acquia’s carries no commerce product at all, so commerce is bought elsewhere	Absent. A commerce engine is integrated over APIs	Either way, catalogue, pricing, tax and checkout form a system with its own release cycle and its own owner
Digital asset management	A DAM module for organising, transforming and distributing assets across brands and channels, commonly licensed apart from the content module	A media library sized for web delivery. Rights, renditions and asset governance at scale need a dedicated DAM	Suite: one asset store shared by every module, and its taxonomy becomes a shared dependency. Headless: a DAM integration, or a decision that the media library is enough
Identity and customer data	A profile store that stitches known and anonymous activity into a single customer record, sold as its own product and frequently its own edition	Absent. Identity resolution belongs to whichever CDP, warehouse or auth provider you choose	Suite: the store is pre-wired to the vendor’s own modules, and any channel outside the suite has to be fed into it. Assembled: the same feeding work, and the schema and store are yours to design

Editions decide what “included” means

The vendor catalogues show how separable these modules are. Adobe documents Experience Manager as a Cloud Service as a set of applications, among them AEM Sites, AEM Assets, AEM Forms, AEM Screens and AEM Edge Delivery Services, each with its own documentation; Assets is described as a cloud-native, PaaS solution for Digital Asset Management and Dynamic Media operations. Adobe’s customer profile product sits elsewhere again: Real-Time CDP is documented under Adobe Experience Platform, in B2C and B2B editions, each offered in Prime and Ultimate packages. Sitecore’s documentation index lists Experience Manager, Experience Platform, Content Hub, CDP, Personalize, Send, Search, Discover, OrderCloud and Experience Commerce as separate products. Optimizely documents a Content Management System in both PaaS and SaaS forms alongside Configured Commerce, Campaign, Data Platform, Content Recommendations, Search & Navigation and several experimentation products. Acquia’s documentation covers Cloud Platform, Site Factory, Acquia Source, Acquia DAM (Widen), Campaign Studio, Acquia CDP, Web Governance, Content Optimization and Conversion Optimization.

Feature lists do not show which tier each capability sits in. Sitecore’s architecture documentation states where its own line falls: XM “refers to the web content management (WCM) core”, encompassing “the creation, management, personalization, and publishing of content”, while XP roles “extend the content management, personalization, and delivery features of the XM” with xConnect, the services that collect and search experience data, and xDB, the storage roles that hold and process it. Content personalisation and behavioural personalisation land on opposite sides of that line, and a comparison chart calls both of them personalisation. Optimizely’s DXP documentation describes “an end-to-end, full-stack digital platform service package that includes content management, digital marketing, enterprise search, and digital commerce in a single cloud service”. That is the description of the package. Which of those parts any one customer is entitled to is set by the order form.

Analysts define the category and rank vendors within it

Industry analysts define the category and rank vendors within it. Gartner publishes a Magic Quadrant for Digital Experience Platforms, and the definition quoted above comes from Adobe’s own announcement of its 2020 placement in it. The label therefore names a market segment and a purchasing model. It does not fix a technical architecture: two products can both be described as DXPs and bundle substantially different things, and the commerce and customer-data rows above are where that divergence shows most.

What “DXP partner” means, and how a suite compares to a composable stack

“DXP partner” describes an agency or systems integrator holding a formal, tiered relationship to one of these vendors, awarded through that vendor’s own partner program. Each vendor runs its own partner program, and the tiers gate what a partner is entitled to sell, how it is trained, and how it is paid.

Sitecore’s program includes Gold and Platinum tiers and, since a July 2025 program expansion, a new Diamond tier the company describes as spotlighting partners who “bring differentiated value through industry-specific use cases, migration accelerators, and AI-powered content and data solutions.” Gold and Platinum partners get marketing-development-fund redemption on approved activity, and Sitecore pays commission on the first-year contract value for partners who influence a licence renewal. Adobe’s Digital Experience Partner Program has four levels, Community, Silver, Gold and Platinum, with published thresholds: Silver requires 30 certifications, 10 customer deployments and 1 specialisation at a $3,000 annual fee, Gold requires 100 certifications, 20 deployments and 5 specialisations at $15,000. Optimizely runs separate Solution Partner and Technology Partner programs, each with its own published terms and application process. Acquia runs a partner finder whose directory filters partners by tier, Elite among them.

A partner’s tier is a fact about that agency’s standing with one vendor. It says nothing about whether the underlying suite is the right architecture for a given buyer, and it does not carry over between vendors: a Sitecore Platinum partner holds no standing on Adobe’s ladder.

The commercial pull behind a “DXP partner” search usually sits next to a second, harder question: whether to stay inside a bundled suite at all, or move the same capabilities onto a composable architecture of separately chosen tools. A DXP partner is generally paid to implement and extend the suite it is certified on, which means its advice on staying versus leaving is not neutral by default. Weighing that trade-off is covered under vendor lock-in, and what actually happens if the answer is to leave is covered below.

The integration arrives assembled, and the pricing covers the platform

A DXP ships with its own integration already done. When the bundled tools fit how a team works, having them pre-connected under one vendor and one contract removes real assembly effort, and one supplier is accountable for the whole stack when something breaks between modules. The third column of the table above lists what assembling the same set separately asks of you instead: a front end to build, host and maintain, a decisioning service and somewhere for profile data to sit, an agreed identity key between the content and campaign tools, instrumentation on every surface that has to appear in reporting, and either a DAM integration or a decision that the media library is enough. Each of those is an engineering item, a supplier relationship, or both, and no one vendor answers for the result when two of them disagree. For organisations that will use most of the bundle, that is a sound trade.

The same structure sets the terms of any later change. Buying the suite usually means taking modules that go unused, and replacing one of them with a standalone tool costs more work the more tightly it is integrated with the rest. Pricing covers the platform, so utilisation of individual modules rarely moves the bill. The approach of assembling the same capabilities from separately chosen parts is composable architecture, and MACH names one formalisation of it. What a headless CMS covers on its own is set out under headless CMS.

What leaving a DXP involves

A DXP exit separates into four bodies of work that move at very different speeds.

Content and assets. This is the tractable part, and every suite documents a programmatic handle on its content. AEM stores content in a Java Content Repository, the JSR 283 standard that specifies “a vendor-independent and implementation-independent way to access content bi-directionally on a granular level within a content repository”, with nodes defining structure and properties holding the content and metadata. Sitecore Content Serialization is documented as “a system for serializing, sharing, and deploying content items, as well as keeping them in version control”. Optimizely documents a CMS (SaaS) REST API that “lets you manage content items and their versions in Optimizely CMS (SaaS) programmatically”, covering creation, copying, updating, status transitions, deletion and version listing. An Acquia-hosted site is a Drupal site, and Drupal’s JSON:API module is part of core: it “implements the JSON:API spec for Drupal entities” and gives “RESTful CRUD for a Drupal site’s content” with no configuration required, so every entity type and bundle is readable over HTTP. Reachable content still carries the modelling work: rich text, component structure, reference fields and localisation all have to be rebuilt on the destination.

Templates and front-end code. These do not port. Suite templating is specific to the platform, and the delivery tier it renders through is part of the product. This is what makes a platform move a rebuild, a point covered in replatforming.

Personalisation rules, audience definitions and campaign configuration. These live in vendor configuration with no neutral interchange format, so they are re-expressed on whatever comes next. Auditing the active set before the migration is scoped sets how much of the new stack has to exist on day one.

Behavioural history and analytics. Segment and report definitions can be rewritten. Accumulated event history in a vendor’s profile store generally stays where it is, and teams either export a flat archive for reference or accept a break in the series at cutover.

Two things shape the sequence. Suites are commonly bought on a single contract, so removing one module opens a commercial negotiation, and notice periods and term end dates decide when a move can land at all. The modules also depend on each other asymmetrically: personalisation and analytics typically read from the content delivery tier, so moving the CMS forces a decision on both, while replacing an email tool leaves the CMS untouched. Staged exits usually start with the piece that has the clearest export path.

Why organisations leave

The reasons repeat across the category, and most are commercial or operational.

• Utilisation against the bill. A suite is priced as a platform. At renewal the comparison is the whole fee against the modules genuinely in use, which is often the CMS and one other. The full cost picture is set out under CMS TCO, and the pre-negotiation checklist covers what to establish before the vendor conversation opens.
• Overlapping tools already in place. Marketing teams buy their own analytics, email and experimentation products, so the suite’s equivalents sit idle while both lines are billed. That accumulation is the subject of the shadow stack.
• Support deadlines. Major versions reach published end-of-support dates, and the upgrade frequently amounts to a re-implementation, which reopens the platform question. Dates for several products in this category are listed on the CMS end-of-life page.
• Repackaging. Vendors move capabilities between editions and rename products. Something bought in one edition can require a different one after a portfolio change.
• Front-end constraints. Performance work, framework choice and design-system reuse all run through the suite’s delivery tier, which limits how much of that work a team can own.
• Staffing. Suite work needs platform-specific experience, which narrows who can be hired or contracted for it and lengthens replacement time when a team turns over.

None of this makes the suite model a poor buy. It suits an organisation that wants one supplier accountable across content, campaigns and data, and that will use enough of the bundle to justify the platform fee. The exit costs it creates are catalogued under vendor lock-in. WAYF publishes platform-specific accounts of what a move actually involves, for Sitecore, Optimizely, Adobe Experience Manager and Drupal. Payload is the destination in each, so they are most useful for what they record about the source side, which holds whichever destination a team picks, another suite included. A pre-migration checklist for non-technical teams covers the groundwork ahead of any of them.