How to choose the right CMS: a practical guide

This guide is based on our webinar and white paper How to choose the right CMS for your organization. In it, leaders from four Umbraco partner agencies, who between them have taken part in many CMS selections, discussed the process with two people from Umbraco's product team. You'll find who they are further down the page.

The CMS market moves fast. Bolette Kern, Product Manager for the CMS at Umbraco, describes how quickly the conversation has shifted. A few years ago the industry was focused on MACH (microservices, API-first, cloud-native, headless). Then traditional CMSs added headless capabilities, and the debate became headless versus hybrid. She sums up the market as fast-moving, crowded, competitive and noisy.

Part of the noise comes from rankings. Analyst reports can give you an overview, but different reports measure different things and don't always include the same products, so it's easy to end up comparing apples and oranges. Emiliano Bottaioli, CTO at Sampson May, puts it this way: being named a leader in a category is great for marketing, but it doesn't necessarily mean that CMS is the right fit for you.

That's why the steps below start with your organisation, not with the market.

Before you look at any product, ask why you're changing at all. Niels Brinkø, CTO at Kruso, suggests checking whether it's really the CMS you need to replace, or a website or digital experience that no longer supports the business. He's seen many organisations point at a product and say "we need a site on that platform", when what they need is a digital experience that supports their business and tools that support their editors.

Write down what the new CMS should make possible, for example:

• publishing campaigns without waiting for a developer

• launching new markets and languages faster

• clearer governance and approval flows

• delivering content to apps, screens or other channels

• connecting content with commerce, CRM or marketing automation

A CMS affects more people than most software. If only IT or only marketing decides, you'll find the gaps after launch.

Bring in:

• Content editors, who'll use the system every day

• Developers, who'll build, extend and maintain it

• Marketing, who care about speed, campaigns and analytics

• IT and security, who own hosting, access and integrations

• Legal or compliance, especially in regulated sectors, for data protection (GDPR), accessibility and industry rules

You don't need everyone in every meeting. You need their requirements on the table before you shortlist.

Emiliano Bottaioli sees a common mistake: clients putting an enterprise CMS, an open source CMS and a simple website builder side by side, as if they did the same job. Know which category fits before you compare products.

Many CMSs now span more than one type, for example an open source CMS that also works headless. Read more: What is a CMS? · What is a headless CMS? · CMS vs DXP

Jason Prothero's point: if you buy an enterprise CMS with a thousand features and only use ten of them, you're paying for complexity you don't need.

Turn your goals from step 1 into requirements, grouped into areas like these:

Ask "why" two or three times. For each major feature, ask why you need it. If there's still a good business reason after a few rounds, keep it. If the answer ends with "because a competitor has it" or "someone said it's a good idea", look again, since every feature costs something.

Give non-negotiables a measurable target. For example, don't just write "accessible", write which WCAG level. Don't just write "always available", write the uptime you need. Each step up costs more, so be precise about what regulation or your business really requires.

Use the CMS as a hub, not a do-everything tool. Jason describes CMSs being stretched into document management systems with heavy approval chains. A CMS can do light work in neighbouring areas like product information or digital assets, but past a certain point it's better to integrate a specialist system and let the CMS bring the content together.

Then weight everything in a scorecard. Mark each requirement as a must-have or a nice-to-have, give each area a weight, and score every shortlisted CMS against it. If everything is marked critical, you haven't prioritised yet.

Plan in phases. Nik Wahlberg's experience is that most RFPs contain "the kitchen sink". Decide what you need at launch and what can follow in a second or third phase. It's easier to hit the mark first time with a tight scope.

Narrow the field with what you already know. Jason Prothero suggests starting from your team. Which technology stack does your IT department work with, for example Microsoft or Linux? Who'll help maintain and develop the site, and which technologies do they know?

Shortlist three or four options, ideally of different types, so you see real alternatives. Then test them yourself. A sales demo shows the best path through the product; your editors will meet all the other paths.

Give your editors real tasks, with your own content:

1. Create a new page with text, images and a form, and publish it.

2. Reuse a content block on several pages, then change it once.

3. Translate a page into a second language.

4. Schedule a page and send it for approval.

5. Roll back to an earlier version of a page.

Watch whether the editing experience suits your team. Jason noted that experienced editors can handle a lot of design freedom, while others get overwhelmed by too many options and work better with a more controlled setup.

Ask to see the backoffice of real, live sites, as well as the demo environment. Emiliano Bottaioli recommends asking agencies to show how they implemented earlier projects. Few buyers ask to see the backoffice, even though editors will live in it every day.

If you write an RFP, describe scenarios and keep it focused.

• "Our marketing team needs to launch a campaign page in three languages without developer help" tells you far more than "Multilingual: yes/no".

• Emiliano's warning: when an RFP lists everything, agencies have to price everything, and you pay for capabilities you may never use.

• Nik's advice: aim for a handful of quality responses rather than fifteen, and talk to the bidders instead of judging on price alone.

The licence is rarely the whole story. Work out what the CMS will cost over at least three to five years:

• licence or subscription

• implementation and development

• hosting and infrastructure

• support and service levels

• upgrades and ongoing maintenance

• integrations and their upkeep

• training and onboarding

• your own team's time

• the cost of leaving again, if you ever need to

Know how the costs arrive. Neither SaaS nor self-hosted is free to run. With SaaS, you pay a subscription continuously and the platform is upgraded for you. With a self-hosted CMS, upgrade and maintenance costs come in larger chunks at intervals, so you need to save up for them.

Check for lock-in before you sign. Jason Prothero's red flags were about ownership and exit: who owns the code, and can you leave a vendor or partner without starting over? Ask:

• Can we export all our content and data in a usable format?

• Do we own the code that's built for us?

• Can we change implementation partner without changing platform?

• Can we choose where and how the solution is hosted?

• Can we connect the tools we already use through open APIs?

• Do the licence terms or contracts make it hard to leave?

When to bring in a partner. Niels Brinkø's rule of thumb: if you don't have the skills in-house, if it's a long time since you last did this, or if the project starts to feel too big, bring someone in. Even a short consultation early on can help you narrow the field. He also suggests being honest about whether your team's experience is recent, because the market moves fast.

Some partners will also help you write the RFP, which helps you ask the right questions from the start.

Questions to ask a potential partner:

• Have you worked with organisations like ours, in size, sector and technology?

• Can we see the backoffice of a site you've built and still maintain?

• Can we speak to references?

• What happens after the site goes live? Some partners hand over and leave; others stay for the long run.

• How do you handle upgrades, security updates and incidents?

• Who from your team will we actually work with?

You can choose the CMS first and then the partner, or let a partner guide the selection. Either way, keep the requirements and the final decision in your own hands.

A CMS needs regular updates, security patches and performance work. Nik Wahlberg shares an example: a client postponed CMS updates for years to save money, until security vulnerabilities forced an emergency migration that cost more than planned upgrades would have.

Nik's advice is to expect the site to keep evolving after launch, since no project ships with every requirement. Agree a regular rhythm with your partner, review analytics and feedback together, and set aside a maintenance budget or retainer that fits your volume.

Before you decide:

• Check the vendor's release cadence and support periods. How often are new versions released, and how long is each version supported?

• Budget for maintenance as a running cost, not a one-off.

• Plan for growth in traffic, content, languages and integrations.

• Leave room for new technology, such as AI-assisted editing or personalisation, without needing a rebuild.

• Choosing on trends or rankings instead of your own requirements

• Letting the feature list grow until scope and budget get out of hand

• Buying for features you won't use, and paying for the complexity

• Forcing the CMS to do another system's job, instead of integrating

• Letting one department decide for everyone who'll use the system

• Trusting the demo instead of testing with your own editors

• Comparing licence prices only, and ignoring total cost of ownership and lock-in

• Treating launch as the finish line, with no plan or budget for maintenance

The partner agencies highlighted a few things from their own projects:

• No licence fee for the core CMS, so more of the budget can go into the solution itself. You pay for add-ons, such as personalisation, only when you need them. You still need to budget for hosting, development and maintenance.

• Flexibility to fit the business: one panellist describes Umbraco as a blank slate, which is both the most daunting and the best thing about it, because you build what the business needs instead of bending a bundled tool to fit.

• Room to grow: Emiliano Bottaioli described clients that started small and grew to listed companies on the same platform.

You can host Umbraco yourself or use Umbraco Cloud for managed hosting, and work with one of our partners. Umbraco publishes its release cadence and long-term support periods, so you can plan maintenance from the start.

It isn't the right fit for every project, and that's the point of a structured selection: let your requirements decide.

The advice in this guide comes from:

• Emiliano Bottaioli, Chief Technology Officer, Sampson May

• Niels Brinkø, Chief Technology Officer & Partner, Kruso

• Nik Wahlberg, Founder & CEO, Scandia

• Jason Prothero, President, ProWorks Corporation

• Bolette Kern, Product Manager, CMS Group, Umbraco

• Rune Strand, Product Communications Manager, Umbraco