A content management system is the screen your team logs into to change the website. Choosing a CMS is therefore a decision about people, not software. The right one lets the person who spots a mistake fix it. The wrong one turns every small change into a request nobody wants to send.
Most advice on this subject starts with features. This one starts with your team, because a tool your team avoids is a tool that quietly freezes the website. The choice also belongs inside the wider plan for a web or app project, where it usually happens far too early.
What choosing a CMS actually decides
Three things, and the rest is decoration.
First, who can publish without asking a developer. Second, what a page can hold, which is the shape of your content. Third, how much it will cost to leave once the business outgrows it.
Dashboards, themes and dark mode stop mattering after the first week. Those three questions still matter in five years.
Start with the people who will use it
People choose software on features and abandon it on friction. So name the handful of people who will touch the system every week. Then write down what each of them needs to do, in their own words.
Who publishes, and how often
A site that changes twice a year needs very little. A site with a weekly article, a jobs page and three editors needs roles, drafts and a review step. Count the publishing rhythm you really have, rather than the one in the plan.
What a page has to hold
Take your most awkward page and describe its parts out loud. A service page might need an area list, two testimonials and a block of questions. If the system keeps all of that as one long blob of text, every later change becomes a copy and paste job.
The three shapes most systems take
Almost every option is a version of one of three. A hosted platform runs the software for you and charges monthly. An open system sits on hosting you rent, with plugins filling the gaps. A headless system holds the content and hands it to a site your developer builds.
| Shape | Suits | The catch |
|---|---|---|
| Hosted platform | Teams who publish ordinary pages | Usually you live inside its limits |
| Open system on your own hosting | Teams who need plugins and control | Updates and backups become your job |
| Headless, with a custom admin | Content that feeds more than one place | Nothing appears until a developer builds the front |
None of the three wins in the abstract. Each one trades control against effort, so choosing a CMS mostly means picking the trade you can live with.
The features worth choosing a CMS for
Six things earn their place. Treat the rest of the list as noise.
- Roles and permissions, so a new starter cannot publish to the homepage by accident.
- Drafts with a preview that shows the real page rather than an approximation.
- Named fields instead of one big text box, because named fields keep a page consistent.
- Media handling that sizes pictures for you, since nobody remembers to do it by hand.
- Web addresses that survive an edit to the headline.
- An export of everything, in a format a person can open and read.
What a demo will not show you
Every demo runs the happy path on prepared content. Ask about the awkward parts instead.
What happens when two people edit the same page at once? Where does a picture live after somebody removes it from an article? How many clicks does a small text change take, from logging in to seeing it live?
Then ask who fixes the site when it breaks on a Monday morning. Usually the answer is your developer, your hosting company, or nobody at all. Knowing which one before you sign matters more than any feature list.
Choosing a CMS you can leave later
Every system is temporary, so judge the exit as carefully as the entrance. Three questions cover most of it.
- Can you export the content as files you can open and read?
- Do you hold the domain and the hosting account in your own name?
- Will your web addresses survive a move, or does the platform invent its own?
That last question decides whether a future redesign keeps the traffic you have already earned. A platform that rewrites every address makes the next move expensive, and the bill arrives years after the decision.
What choosing a CMS really costs to run
The licence is the visible part. Underneath it sit hosting, plugin renewals, updates, backups and the hours somebody spends keeping the thing current.
Those hours are the part people forget, and they arrive every month whether the budget mentions them or not. So read what maintenance really involves before treating a free system as a free one.
A worked example, with round numbers chosen to make the arithmetic easy rather than to describe your site. Say one page takes twenty minutes to publish, and your team publishes four pages a week. That is eighty minutes a week, or one working day every six weeks. Halve the time with a better editing screen and you free about half a day every six weeks, which is what a smoother publishing flow is really selling.
Who patches it, and when
An open system with many plugins has many doors. Somebody has to keep them locked, which means applying updates while they are still small. Left alone, they turn into the kind of hole somebody else finds first.
So settle who does that work before you sign, and write it down. Ask who applies the updates and how often. Check whether there is a copy of the site to test them on first. Then ask who fixes the page when an update breaks it on a Friday afternoon.
Updates do break things, usually where two plugins meet. A hosted platform absorbs that work and charges for it in the monthly fee. Either way, the basics of keeping a site safe stay with you, because whoever owns the domain owns the problem.
Build or buy, and the honest answer
Most businesses should buy. A standard system handles ordinary pages perfectly well, and the money belongs on the part of your site nobody else sells. That is the same test as deciding when a custom build pays.
A custom admin screen earns its keep when your content has an unusual shape, or when the editing job is specific to your trade. Otherwise you have paid to rebuild something that already existed.
Test before choosing a CMS, rather than reading about it
A review describes a tool. A trial describes your team using that tool, which is the part you actually need to know.
Pick the hardest real page you own, then build it twice, once in each shortlisted system. Give the trial to whoever will publish, not to whoever will sign. Watch where they hesitate, and count the questions they have to ask.
If a good writer cannot get a page live in an afternoon, no feature list rescues that.
When choosing a CMS is the wrong project
Sometimes the tool is not the problem. Slow publishing often comes from an approval chain rather than from software. A site nobody updates usually lacks an owner, not a better editor.
Moving everything to a new system is a project in its own right. You have to redirect every address that changes, and anything you miss is traffic you lose. So move when the current system blocks work you genuinely need to do, and not because a demo looked cleaner than the screen you have.
How to decide without dragging it out
- List the people who publish, and what each of them changes.
- Describe your most complicated page, part by part.
- Shortlist two systems, never five.
- Rebuild that page in both, using your own words and pictures.
- Ask each vendor to show you how you would export everything and leave.
Then decide with the people who will use it in the room. Choosing a CMS well is mostly a matter of asking the boring questions early, while changing your mind still costs nothing.
Frequently asked questions
What does a CMS actually do?
A CMS is the screen your team logs into to change the website without touching code. It holds your pages, articles, pictures and settings, then builds the page a visitor sees. Some systems also handle forms, users and permissions. The important part is never the length of the feature list. It is whether an ordinary member of staff can publish a page on a busy Tuesday without asking anyone for help.
Who should be involved in choosing a CMS?
The people who will publish, first of all, and whoever pays the invoices. A developer belongs in the room to check the technical claims, though the deciding vote should sit with the team doing the daily work. Software picked only by the person who signs for it tends to sit unused. Ask each publisher to finish one real task during the trial, then compare notes before anyone commits to anything.
Is an open source system cheaper than a hosted one?
Not usually, once you count the hours. The licence costs nothing, yet somebody still has to apply updates, renew plugins, take backups and sort it out when one plugin argues with another. A hosted platform folds that work into a monthly fee and takes the decisions away from you. Cheaper therefore depends on whether you have someone to do the work, and on what their time is worth to the business.
What does headless mean, and do we need one?
Headless means the system holds your content and hands it to whatever displays it, instead of producing the pages itself. It suits a business feeding one set of content to a website, an app and a screen in a shop. Most single websites do not need it, because it moves work to a developer for flexibility nobody uses. Pick it when more than one place genuinely consumes the same content.
How do we keep control of our own content?
Own the domain and the hosting account in your own name, and never let a supplier hold either on your behalf. Then ask what an export actually leaves behind. The words and the pictures usually travel. The layout, the form entries and any redirect rules often do not, because those live in the platform rather than in your content. Ask to see a real export during the trial, then open the file yourself. A file you cannot read is not a way out.
How long should choosing a CMS take?
Weeks rather than months, for most businesses. Two candidates, one real page built in each, and a conversation with the people who publish will answer the question. Long selection projects usually stall because the list of options keeps growing. So shortlist two, set a date for the decision, and treat anything you cannot test in a fortnight as a reason to drop it rather than a reason to extend.
Does the CMS affect how fast our pages load?
It influences speed, though it rarely decides it. Heavy themes, stacked plugins and pictures nobody resized usually slow a site more than the underlying system does. A good system helps by sizing images and caching pages for you. Still, a careless build will feel slow on any platform, so measure speed after launch rather than trusting the numbers on a sales page.
What should we test before choosing a CMS?
Publish a real page, never a sample one. Add a picture, change a headline, schedule an article and then ask a colleague to review it. Try the parts that worry you, such as a table, a form or a long list of services. Judging a demo means watching somebody else handle their own content, which tells you very little about your own week.
When is changing our CMS the wrong move?
When the real problem is people rather than software. Approval chains, missing owners and unclear responsibilities all survive a migration. They slow the new system in exactly the same way. So run one honest test first. Name a single owner, give them the right to publish, and see whether the queue clears. If it does, the tool was never the blocker. Choosing a CMS again would only buy a different screen to wait behind.