How to choose a CMS you won’t regret in 2 years

Most CMS decisions I’ve watched go wrong didn’t go wrong at the demo. They went wrong three months earlier, when nobody wrote down what the thing actually needed to do. By the time you’re comparing vendors, you’re comparing them against a vague sense of “better than what we have,” and that’s how teams end up with a platform that’s genuinely impressive and genuinely wrong for them.

So this is a guide to choosing a CMS that spends most of its time on the part before the shortlist. If you get your requirements right, picking between the final two or three is comparatively easy. If you get them wrong, no amount of demo-watching saves you.

The short version: work out who has to use it, what content you actually have, where that content needs to go, and what your team can realistically maintain. Then shop.

Get your requirements straight first

Before you look at a single product, you need answers to four questions. They sound basic. Most teams can’t answer them cleanly, which is precisely the point.

Who actually uses this thing, and how often? Not who signs the contract. Who logs in on a Tuesday to change a headline. If that’s five marketers with no technical background publishing daily, ease of use isn’t a nice-to-have, it’s the deciding factor. If it’s two developers who deploy through a pipeline and marketing rarely touches it, you can optimise for flexibility instead. These two situations point at completely different products, and the mismatch between them is the most common source of regret.

What content do you actually have? Go and count. How many pages, how many templates, how much media, how many languages, how many regional variants. Then look at how it’s structured, or whether it’s structured at all. If everything you own is formatted HTML pages built for one template, moving to a system that expects clean structured content is a migration project, not a switch-over. That’s not a reason to avoid it, but it is a reason to budget for it honestly.

Where does the content need to go? If the answer is one website, say so and stop reading the headless marketing. If it’s a website plus an app plus in-store screens, that changes the shortlist substantially. Be honest about the difference between channels you run today and channels someone mentioned in a strategy deck.

Who maintains it after launch? Every CMS needs someone. Upgrades, plugins, integrations, permissions, the slow accumulation of half-broken things. If you don’t have in-house technical resource, a SaaS product where the vendor handles the infrastructure is worth paying for. If you have a strong dev team who want control, self-hosted or headless options open up.

Write the answers down. Circulate them. Get your marketing lead and your technical lead to agree on paper before anyone books a demo, because they frequently don’t agree, and finding that out in month six is expensive.

The four shapes you’re actually choosing between

Before individual vendors, you’re choosing an architecture, and narrowing this first cuts your shortlist down enormously. There are roughly four shapes on the market.

A traditional coupled CMS keeps content management and the front end in one system. You pick a theme or templates, you publish, a page appears. It’s the fastest route to a working website and the easiest for non-technical people to operate independently. The limitation is that your content is fairly tied to that website, and doing anything unusual with the front end means fighting the system. For a single marketing site run by a small team, this is more often the right answer than current fashion admits.

A headless CMS keeps only the content management and serves everything through an API, leaving the front end to your developers. Content becomes structured and reusable across a website, an app, a screen, anything. You gain flexibility and usually speed. You give up the ability for a marketer to build a page without engineering help, unless you invest in building that capability. Good fit when you have real channels beyond the website and developers to serve them.

A hybrid or decoupled CMS tries to give you both, API delivery for other channels plus visual editing and preview for the main website. This is where a lot of the mid-market has landed, and for good reason. It’s worth looking at closely if the pure headless tradeoff worries your marketing team, which it usually should.

A SaaS platform is a delivery model rather than an architecture, but it cuts across the others and matters just as much. The vendor runs the infrastructure, handles upgrades and security patching, and you don’t maintain servers. You trade some control and customisation depth for not having an upgrade project every eighteen months. If you lack in-house technical resource, this is usually worth paying for, and the hidden cost of self-hosting is the one teams most consistently underestimate.

Work out which of these four fits your answers to the four questions above, and you’ve eliminated most of the market before you’ve sat through a single demo.

The evaluation, step by step

Once you know what you need, here’s how I’d run the actual process.

Start by writing your requirements as scenarios, not features. A feature list gives you “supports workflow approvals.” A scenario gives you “a regional marketer drafts a landing page, their manager approves it, and it publishes to three locales without a developer.” Scenarios are testable in a demo. Feature checkboxes just get ticked by every vendor, because every vendor technically supports every feature if you squint.

Then separate the must-haves from the wants, and be ruthless. Most requirement lists I see have twenty must-haves, which means there are no must-haves. Try to get to five or six genuine dealbreakers. Everything else is a tiebreaker. This is the single most useful thing you can do to make the decision tractable.

Next, build a shortlist of three to five, and no more. More options don’t produce a better decision, they produce a longer process and a team that’s lost the thread by week eight. Draw the shortlist from products that fit your operating model, so SaaS versus self-hosted, headless versus coupled, before you start comparing individual vendors.

Now run the demos on your scenarios, not theirs. This matters more than anything else in the process. Send your three or four scenarios in advance and ask each vendor to walk through those specifically. A polished standard demo tells you the product photographs well. Watching someone do your actual task tells you whether it fits. If a vendor resists this, that’s information too.

Then get your hands on it. Ask for a trial or a sandbox, and have the people who’ll genuinely use it daily try to complete a real task without help. Not the project lead. The marketer who publishes on Tuesdays. The gap between how a product demos and how it feels on day forty is where satisfaction actually lives.

Check the integrations properly. List every system this has to connect to, your CRM, analytics, marketing automation, commerce, whatever’s on the list, and for each one ask whether there’s a supported integration, a documented API, or nothing. “We have an API” is not the same as “there’s a maintained connector.” Integration work is where CMS projects overrun most often.

Talk to reference customers who resemble you, and push past the ones the vendor hands you. Those are selected and will be positive. Ask for a customer of similar size, in a similar industry, who implemented in roughly the last two years, and ask them the two questions that actually matter: what took longer than expected, and what would they do differently. People are surprisingly candid when you ask it that way.

Finally, work out the total cost, not the licence cost. Licence, implementation, migration, training, hosting if it’s not SaaS, ongoing development, and the internal time nobody puts in the spreadsheet. Implementation frequently costs more than the first year of licence. A cheaper platform that needs heavy customisation can easily end up costing more than an expensive one that fits out of the box.

A requirements template to work from

The hardest part of all this is the blank page at the beginning, so we’ve put the framework into a template you can fill in.

It covers the four questions above, space to write your scenarios, a must-have versus want-to-have split, an integration inventory, and a total cost worksheet that includes the lines people forget. Fill it in with your marketing and technical leads before you contact any vendor. If the two of them fill it in separately and hand back different answers, that disagreement is the most valuable output of the whole exercise, and far better discovered now than after signing.

What the demos won’t show you

A few things that matter enormously and never appear in a sales presentation.

How it feels when it’s full. Every CMS is pleasant with twelve pages in it. Ask to see a large implementation, or ask pointed questions about how search, permissions, and navigation behave with thousands of items and dozens of editors. Products that are lovely at small scale sometimes become unusable at large scale.

What upgrades are actually like. Ask existing customers, not the vendor, how the last major version upgrade went. This is one of the biggest hidden costs in self-hosted platforms and one of the main arguments for SaaS.

How good the documentation is. Go and read it now, before you buy. You’ll be living in it. Thin or outdated docs predict a painful implementation more reliably than almost any other signal.

Whether you can get people. Check whether developers with experience in this platform actually exist in your market and at your budget. A technically excellent product with a small talent pool is a staffing risk that shows up eighteen months later when your one specialist leaves.

What leaving looks like. Ask how you’d get your content out if you switched in five years. Clean export and a documented API mean your content stays yours. If the honest answer is that extraction would be a project, factor that in. You’re choosing what you’ll be tied to, not just what you’ll use.

I’d also gently note that the newest architecture isn’t automatically the right one. Headless and composable approaches are genuinely powerful and genuinely more work. If you have one website, a small team, and no engineering capacity, a well-chosen traditional CMS will serve you better than a modern stack you can’t staff. Choosing the less fashionable option because it fits is a sign of a good decision, not a timid one.

The stuff worth remembering

Most bad CMS decisions are requirements failures, not vendor-selection failures. Do the thinking before the shortlist.
Answer four questions first: who uses it daily, what content you actually have, where it needs to go, and who maintains it afterwards.
Write requirements as scenarios you can watch someone perform, not features that every vendor will tick.
Get to five or six genuine must-haves. If everything is a must-have, nothing is.
Shortlist three to five, demo on your scenarios, then put real users in a sandbox with a real task.
Cost the whole thing: implementation, migration, training, and ongoing development, not just the licence.
Ask about the invisible parts, how it behaves at scale, what upgrades cost, whether the documentation is any good, whether you can hire for it, and how you’d leave.
Match the architecture to your team. The most modern option is not automatically the right one.

Working through a CMS decision?

Before deciding, it is worth being clear on what a CMS is, how it differs from a DXP, and whether a headless CMS suits you.

If you’re partway into this and want someone to pressure-test your requirements before you commit, or to tell you honestly that your current platform is fine and the real problem is elsewhere, get in touch and we’ll go through it with you.