Choose a content management system by testing the tasks your team will do after launch. Someone should be able to make a typical change, preview it, publish it with the right permissions and recover a mistake. Then compare the ongoing cost, support requirements and options for taking your content elsewhere.
A CMS is the part of a website that lets you manage content. The platform name tells you something about its possibilities. The way it has been set up tells you what your team will actually be able to do.
Write down the editing jobs first
List what changes regularly. That might include service descriptions, staff profiles, news, projects, prices, products or opening hours. Put a name beside each task so the design team knows who will be doing it.
Be specific about the content. “Add a project” could mean a title and one image, or several image layouts, a film, credits and a related service. Those are different editing tasks.
Some teams want to change page layouts freely. Others want an editor that protects the layout while they update the information. Decide how much flexibility is useful, and which design decisions should stay consistent.
Ask for a demonstration with your kind of content
A good test uses a normal person from your team and a realistic change. Watching a developer move quickly around their own editor won't tell you whether someone else can use it next month.
- Open a page or create a typical new item.
- Change some text and replace an image.
- Check how the image crops on a phone.
- Save a draft and preview the result.
- Publish through the agreed approval process.
- Restore the previous version or explain the recovery process.
Ask where a mistake could affect the rest of the site. For example, a shared service description might appear in several places. That can save repeated editing, but the person making the change needs to understand where it will appear.
Understand who can change what
A staff member writing an article may need a different level of access from the person managing the whole website. Agree who can edit, who can publish and who can change settings.
Permissions vary by platform and setup. WordPress, for example, defines roles with different capabilities. Its roles and capabilities documentation describes those differences. Ask for the same explanation for whichever CMS is proposed, including any limits imposed by its plan.
Keep business accounts under the business's control and give collaborators the access they need. Confirm the process for removing that access when someone leaves.
Compare the ongoing work and cost
Ask for the recurring costs in writing. Include the platform or hosting, required extensions, editor seats, backups and any support arrangement. Usage or content limits may also matter if the site will grow.
Then ask who handles updates, compatibility problems and failures. The answer can be different for a hosted platform, a site with installed plugins and a custom frontend connected to a separate CMS.
A headless CMS keeps content management separate from the website that displays it. That can be useful when the same content needs to appear in several places. It also means the brief needs to cover both systems and the publishing connection between them. Choose it for a reason you can explain.
Ask about export and recovery
Find out what you can export, in what format and what would need to be rebuilt if you moved. A content export may give you text and records without reproducing the website's design or its connected services.
Backups and exports have different jobs. A backup helps recover the system you already run. An export can help move content into another one. For a WordPress site, the official backup guidance explains the need to account for both files and the database.
Ask who is responsible for recovery and whether the process has been tested. Include media, integrations and any records held outside the CMS in that conversation.
What should be included in handover?
Ask for your own access, a short guide and a walkthrough of the tasks you agreed at the start. The walkthrough should use the finished website rather than an unrelated demonstration site.
It should also explain how to preview changes, what to do if publishing fails and where to get help. If ongoing support is separate, make the boundary clear before launch.
Which CMS is best?
The best choice depends on the content, the team, the connected systems and the support you want to carry. If two proposed platforms both meet those needs, compare the actual editing experience and the total ongoing commitment.
Add your editing tasks to the website brief. They are part of the project, and worth testing before the whole site is built.