CMS vs DXP: which problem do you actually have?

Here’s a conversation I’ve had more times than I can count. Someone’s website is creaking, the team is frustrated, and a vendor has explained that what they really need is a digital experience platform. By the time I’m involved, the budget conversation has already started and nobody has asked the awkward question: is the problem actually the CMS?

Sometimes it is. Sometimes the CMS is fine and the problem is that customer data lives in four places. Those need different answers, and telling them apart before you spend money is worth an afternoon of your time.

So this is the comparison, done honestly. A CMS manages content. A DXP manages content plus customer data plus how experiences get delivered across channels. The second contains most of the first, costs considerably more, and is only worth it under conditions I’ll spell out.

The short version

A content management system is where content is created, stored, and published. It handles pages, media, workflow, and getting things live. Its natural unit is the page, and its natural home is the website.

A digital experience platform does that too, and adds two things on top. It holds data about your customers, building a single view of who they are and what they’ve done. And it uses that data to decide what each person sees, across whichever channels you’re running, not only the website.

If you want the one-line test: a CMS answers what this page should say, a DXP answers what this person should see. Everything else follows from that difference.

The reason the comparison gets muddled is that modern CMS products have absorbed some DXP features, and DXP vendors describe their content module as a CMS. The categories overlap in the middle. What hasn’t changed is the centre of gravity. A CMS is built around content. A DXP is built around the customer.

Where they genuinely differ

Let me go through the differences that actually change your day-to-day, rather than the feature-grid version.

On scope, a CMS is usually website-first. It can often feed other channels, especially if it’s headless, but the workflows, the previews, and the mental model are built around web pages. A DXP assumes from the start that content goes to several places and that those places need different treatment.

On customer data, this is the cleanest dividing line. A standard CMS doesn’t know who’s reading. It has no persistent memory of a visitor and no unified profile. A DXP does, and that’s most of what you’re paying extra for. If customer data isn’t part of your problem, you’re paying for a capability you won’t use.

On personalisation, a CMS might offer basic rules, show this banner to logged-in users, that sort of thing. A DXP treats personalisation as a first-class function with segments, decisioning, and testing built around the customer profile. The gap here is large in practice, larger than the feature lists suggest.

On cost and complexity, a CMS is cheaper to buy, quicker to implement, and easier to staff. A DXP costs more in licence, takes longer to implement, and needs more people to run properly. That last part is the one that gets underestimated most reliably.

On who operates it, a small marketing team can run a CMS. A DXP realistically needs someone owning content structure, someone owning segments and personalisation logic, and technical resource for integrations and front ends. If those roles don’t exist and aren’t being hired, the platform will underperform regardless of how good it is.

The same task, run through both

Abstract comparisons only get you so far, so here’s one ordinary job done in each.

Say you’re launching a product aimed at two quite different audiences, small businesses and large enterprises, and you want each to see messaging that fits them.

On a CMS, you build two landing pages. One for each audience, each with its own URL, its own copy, its own case study. Then you drive traffic to them separately, small business ads to one, enterprise outreach to the other. It works. It’s how a great deal of good marketing has always been done. The limits show up in the gaps. Someone who arrives at your homepage cold sees whichever version you decided was the default. An existing enterprise customer browsing your site gets the same treatment as a first-time visitor. And when you want to change the positioning, you’re editing two pages, then four, then eight as the matrix grows.

On a DXP, you build the components once and let the system assemble them per visitor. Someone whose profile suggests enterprise, because of company size data, because of what they’ve read before, because they came from an enterprise campaign, sees the enterprise proof points on the same URL that a small business visitor sees the small business ones. The homepage adapts rather than defaulting. An existing customer sees something different again, because the system knows they’ve already bought.

Two things are worth pulling out of that. First, the DXP version isn’t better writing, it’s better routing. The copy still has to be good. Second, the DXP version needs things the CMS version doesn’t: reliable data about who’s who, someone to define and maintain those rules, and enough traffic that the segments aren’t three people each. Strip those away and the sophisticated version underperforms the two simple landing pages.

That’s the honest trade. More capability, more moving parts, more required upkeep.

Diagnosing which problem you have

This is the part that saves money, so let me be practical about it. Work through these in order.

Start with what’s actually painful. Write down the three things that frustrate your team most about your current setup. Be specific. “Publishing a landing page takes two weeks because it needs a developer” is a CMS problem. “We can’t tell whether the person on our site is an existing customer” is a data problem. “Our app and our website show different prices” is an integration problem. The category of the complaint usually tells you the category of the fix.

Then count your channels for real. Not aspirationally. If you run a website and nothing else meaningful, a DXP’s core advantage of coordinating across channels has nothing to coordinate. A good CMS, possibly a headless one, covers you and leaves budget for other things.

Next, ask where customer data lives and whether anyone trusts it. If you already have a reliable unified view, whether through a CDP or a well-maintained CRM, you may be able to connect that to a CMS and get much of the DXP benefit without the DXP. If your data is scattered and contradictory, that’s the real project, and it’s worth solving whether or not you buy a platform.

Then name your personalisation use cases out loud. If you can describe two or three specific things you’d change for specific groups of people, and roughly what that’s worth, personalisation is a real requirement. If the honest answer is that personalisation sounds good but nobody’s defined what you’d do, you’re not ready to buy a platform built around it.

Finally, look at your team as it exists today, not as it might exist after a hiring round that hasn’t been approved. Match the tool to the people who’ll operate it on a Tuesday afternoon.

If the pain is publishing speed, developer bottlenecks, or content chaos, that’s a CMS answer. If the pain is fragmented customer knowledge and inconsistent experiences across several channels, that’s the territory where a DXP earns its cost.

A diagnostic worksheet

The five questions above are simple to ask and surprisingly hard to agree on, which is exactly why they’re useful.

We’ve turned them into a short diagnostic worksheet: the questions, a scoring scale, and space to record your three biggest pain points and your candidate personalisation use cases. Run it with your marketing lead, your technical lead, and whoever owns customer data, separately, then compare answers. In my experience the disagreements between those three are more informative than any vendor demo.

What the cost difference really looks like

I’ve avoided numbers here deliberately, because pricing in this market varies so widely by seat count, traffic, and how hard you negotiate that any figure I gave you would be misleading. What I can be specific about is the shape of the difference.

The licence gap is the part everyone sees, and it’s usually the smaller part. The gap that catches people out is implementation and operation. A CMS implementation is mostly content migration and front-end build. A DXP implementation is that plus data integration, plus defining a customer model, plus building the segments and rules, plus connecting the systems that feed it. That work is slower and needs scarcer skills.

Then there’s the ongoing cost, which is the one that gets left out of business cases entirely. Personalisation isn’t a thing you switch on. Someone has to keep the rules current, retire the ones that stopped working, and add new ones as the business changes. A DXP with nobody tending it degrades into an expensive CMS within about a year, and I’ve seen that happen more than once.

So when you’re comparing, compare three-year totals with staffing included, not licence quotes. The answer sometimes still favours the DXP, and when it does you can defend it properly. What you want to avoid is discovering the true cost after you’ve committed.

The middle options nobody mentions

The CMS versus DXP framing is a false binary, and the interesting answers often live between the two.

A headless CMS plus a customer data platform gets you a long way toward DXP capability for less money and with more flexibility. The headless CMS handles structured content across channels, the CDP handles the unified customer view, and you connect them. You take on integration work, but you keep the ability to replace either piece.

A composable stack extends that idea, assembling content, data, personalisation, search, and commerce from separate specialists. This is essentially a DXP you built rather than bought. It suits teams with genuine engineering capacity and specific requirements, and it punishes teams without them.

A modern CMS with personalisation add-ons is the pragmatic middle for a lot of mid-sized companies. Many CMS products now offer basic segmentation and testing, which covers a surprising number of real use cases. If your personalisation ambitions are “show different content to three or four broad audiences,” you may not need a platform built for one-to-one decisioning.

Staying put is also a legitimate answer. If the CMS works and the real problem is that nobody’s structured the content or defined an audience strategy, buying software won’t fix that. It’ll just make it more expensive.

I’d push back gently on the instinct to jump straight to the biggest platform. The most common expensive mistake in this space isn’t buying the wrong vendor, it’s buying a tier above the problem.

The stuff worth remembering

A CMS manages content. A DXP manages content, customer data, and cross-channel delivery. The DXP contains most of the CMS.
The clearest dividing line is customer data. If a persistent, unified view of your customers isn’t part of your problem, most of the DXP premium is going unused.
Diagnose before you shop. Publishing bottlenecks and content chaos are CMS problems. Fragmented customer knowledge across several channels is DXP territory.
Count the channels you actually run, not the ones on the roadmap.
Be honest about who will operate it. A DXP needs more people and more defined roles than a CMS, and that’s where implementations quietly fail.
The binary is false. Headless CMS plus a CDP, a composable stack, or a CMS with personalisation add-ons all sit in between and often fit better.

Want a second opinion before you commit?

It helps to have the pieces straight: what a DXP is, what a CMS is, and how to choose the right CMS.

The useful version of this conversation starts with your three biggest pain points and an honest look at where your customer data sits. If you’d like someone to work through that with you, and tell you plainly if the answer is “your current CMS is fine, fix the content model instead,” get in touch.