Choose a CMS around your team’s real work

Describe what people will actually publish

List real content: service pages, news, records, documents, languages and media. For each type, identify useful fields, relationships and update frequency. A demonstration with an empty page will not reveal the difficulties of a long record, translation or correction.

Identify who writes, reviews, approves and publishes. Ask the future team to create a page, save a draft, fix a link, replace an image and find the previous version. Permissions should reflect those responsibilities rather than rely on a shared administrator account.

• Three representative items to recreate.
• Editing and approval owners.
• Draft, publication and correction steps.

Compare the same scenario in each candidate

Have each candidate perform the same work using representative content. Fictional example: an editor corrects a translated record with a long title and image, then previews, submits or publishes according to their role. Record what comes from core features, plugins or development. Assess search, URLs and image alternatives on the public result.

Assess the public website separately: speed, component accessibility, mobile behaviour and control over generated HTML. A comfortable editor is insufficient if the result is heavy or hard to fix. The website brief guide helps set criteria before the demonstration.

Test permissions using a demonstration account matching the future editor. With default WordPress roles, Author can publish their own posts, but this does not grant publish_pages or editing other people’s posts. Contributor can prepare their own posts without publishing and has no default upload_files capability. A team editing service pages therefore cannot choose a role from the word “author” alone. The table shows selected capabilities, not a complete permission list.

Check both an allowed operation and one that must be denied, using test content. The documentation distinguishes roles from capabilities: plugins and customisations can change them, while Multisite introduces administration differences. Record content type, post ownership and document status. A hidden menu alone does not demonstrate server-side denial. Keep the observed result with the tested configuration instead of expanding permissions to bypass a failure.

Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

Cost the operation and the exit

Add hosting, subscriptions, add-ons, maintenance, backups, training and editing time. For a hosted product, check plan limits and data retrieval. For a managed installation, assign updates, dependencies and incidents. Total cost depends on architecture and contract, not merely the entry price.

Request a test export of content, media, URLs and metadata, then check what can actually be reused. A text export is not necessarily a restorable website backup. The WordPress export documentation illustrates this distinction for that system; adapt the test to your choice.

Compare exit procedures using content with relationships: category, author, language edition and image. Record retained identifiers and how files can be retrieved. Imported text without its category, or an image still served by the old website, does not establish independent recovery.

For WordPress, distinguish the content WXR from files, theme and plugins. For a Shopify catalogue, distinguish product data, image URLs and inventory. Request a trial reimport before choosing a solution, observing reformatting and configuration work separately.

• Total cost and update owner.
• Export format and completeness.
• Ability to recreate a page outside the chosen system.

Keep the evidence behind the decision

Keep observed gaps and identify who accepts each compromise. Fictional example: a system publishes easily, but an editor cannot restore an earlier version without help; that time and dependency belong in the decision. Try a pilot page through the complete workflow before replicating its model. Identical feature lists do not establish identical autonomy.

Keep content ownership within the organisation and document handover. At acceptance, perform routine tasks without the supplier: edit, publish, revert and export. Observable independence is more useful than a product feature list.

Let the future editor do the work

During the trial, ask the future contributor to correct a price, replace an image and its alternative, and schedule publication. Record required permissions and recoverable mistakes. A demonstration performed only by a salesperson cannot establish the team’s autonomy after handover.