CMS Selection Checklist: Questions to Ask Before Choosing a Platform

A CMS demonstration usually shows the platform at its most comfortable: prepared content, an experienced presenter and a clean publishing journey. Your editorial team will encounter a less tidy reality. Authors leave fields incomplete, campaigns arrive late, translations change independently, and someone needs to correct a published page during a busy afternoon.

A useful CMS selection checklist brings those conditions into the evaluation. It asks what the platform can do, how your team will do it, and what evidence supports the answer. This gives business owners, content teams and developers a shared basis for choosing a system.

Use the questions below to build a shortlist and a practical trial. Record whether each requirement is supported directly, needs configuration, depends on an extension or requires custom development. That distinction will matter long after the sales presentation ends.

What content are we actually managing?

Begin with an inventory of content types and their relationships. A service website might contain services, staff profiles, locations, case studies and articles. A larger organisation may also manage documents, events or product information shared across several sites.

• Which content types have their own fields and lifecycle?
• Where is the same information repeated today?
• Which relationships must editors maintain?
• What content should be archived, redirected or excluded from migration?

Ask the vendor or implementation team to model a representative example. A case study might need a sector, related services, approved client attribution and reusable images. Check whether editors can manage those relationships clearly without copying text between pages.

Watch for a mismatch between structured content and unrestricted page building. Flexible layouts can support campaigns, while structured fields can protect consistency and reuse. Many organisations need both. Decide which parts should be flexible and which should remain controlled rather than choosing one approach for every page.

Can the people doing the work use it effectively?

Include authors, reviewers and occasional contributors in the trial. Experienced administrators can often work around awkward interfaces that other users will find confusing. Test the tasks each role performs most frequently and the tasks they perform under pressure.

• Can an editor create a complete item without developer help?
• Are required fields and validation errors understandable?
• Can someone find and update older content efficiently?
• Does the interface work with the assistive technology our team needs?

Use realistic content lengths, image sizes and incomplete drafts. Ask a participant to correct a mistake, replace an image and locate a page created by another person. Observe where they hesitate and what information they need. Do not let the presenter perform every task on their behalf.

Record training needs as part of ownership cost. A sophisticated system may still be appropriate, but its learning demands should be explicit. If the organisation has many occasional editors, simplicity and clear constraints can be more valuable than an extensive set of rarely used controls.

Does the workflow match how publishing decisions are made?

Describe your actual approval process before evaluating workflow features. Identify who drafts, reviews, approves and publishes each content type. Some organisations need a single reviewer; others have separate subject, brand and legal reviews. Avoid adding stages solely because a platform supports them.

• Can roles act on the appropriate content and sites?
• Can reviewers see the proposed change clearly?
• Can rejected work return to the author with useful feedback?
• Can urgent corrections follow an agreed, auditable process?

Test a revision to an already published page. Determine whether the existing version stays live while the change is reviewed. Check preview behaviour, scheduled publication and what happens if an approval is withdrawn. These details often matter more than a workflow diagram.

Ask how the team handles absence. A single required approver can become a bottleneck without delegation or an escalation path. Also check how access is removed when a contributor leaves and whether ownership of their drafts can be transferred safely.

Will preview and revision history support confident changes?

Editors need to understand what will appear before it is published. Preview should represent the actual rendering context closely enough to reveal layout and content problems. For a headless implementation, confirm that the proposed front-end integration includes preview rather than assuming the CMS supplies the entire experience.

• Can reviewers preview unpublished related content together?
• Can a campaign be checked across relevant screen sizes?
• What changes appear in revision history?
• What does restoring an earlier version do to related records?

Try restoring a deliberately changed item in a test environment. Confirm whether the action creates a new revision, replaces the current state or affects publication immediately. Include media and relationship changes in the experiment where they matter to your content model.

Clarify the difference between editorial revision recovery and system backup recovery. A page history may help undo a copy change but may not recover a deleted media library or damaged configuration. Both kinds of recovery need an owner and a tested procedure.

How will accessibility be supported?

Evaluate both the authoring interface and the content it produces. W3C's Authoring Tool Accessibility Guidelines address these two areas separately: access for authors and support for creating accessible content. A platform choice should account for both.

• Can editors supply appropriate alternative text and meaningful link text?
• Do templates preserve sensible heading structure?
• Can authors create tables and media with necessary supporting information?
• Which accessibility problems are prevented, detected or left to review?

No CMS setting guarantees that every published page will be accessible. The implementation's templates, components and editorial practices all contribute. Ask the delivery team to demonstrate accessible examples and explain the review process for content that editors can customise.

Be especially careful with unrestricted embedded code and third-party widgets. They can bypass the design system and introduce inaccessible interactions. Decide who may add them, how they are reviewed and how the team will replace them if they stop meeting the site's needs.

Can we manage search visibility and content changes?

Check the controls needed for search presentation and site maintenance. Editors should be able to manage relevant titles, descriptions and URLs within clear rules. The implementation should also handle technical concerns consistently rather than making every author a search specialist.

• What happens when a published URL changes?
• Can redirects be created, reviewed and exported?
• How are canonical references and indexing settings managed?
• Can content be organised without creating accidental duplicate pages?

Test a renamed page with existing internal links. Determine whether links update automatically, require editorial work or depend on a separate process. A platform's ability to store a redirect does not prove that the whole migration or editing workflow handles it correctly.

Discuss performance with the implementation team using representative pages and content volumes. Hosting, front-end code, caching, images and integrations all affect the result. Ask for an explanation of the proposed delivery architecture rather than accepting “fast” as an intrinsic property of the CMS brand.

What do localisation and multiple sites require?

If multilingual publishing matters, test the actual translation workflow. Languages may have different publication dates, review responsibilities and content availability. A simple duplicate-page feature may not provide the relationship management the team needs.

• Can each language progress independently through review?
• How are translators shown source changes?
• What appears when a translation is missing?
• Which content and design rules are shared across sites?

Use content with longer translations and different layout requirements in the trial. Confirm how links, media, navigation and metadata are localised. Where the business uses external translation services, verify the integration and its error recovery rather than treating export as a complete workflow.

For multiple sites, clarify administration boundaries. A central team may need shared components while local teams control their own pages. Check whether permission rules, release processes and reporting can support that arrangement without copying the entire platform for every site.

How will the CMS connect to other systems?

List the systems that supply or consume content: product databases, CRM tools, search services, marketing systems and mobile applications. For each connection, define the direction, required fields and acceptable delay. “Has an API” is a starting point for investigation.

• Are the required read and write operations available?
• Can changes be detected without repeatedly downloading everything?
• How are credentials, permissions and usage limits managed?
• Who investigates a failed or delayed synchronisation?

Run a small integration experiment with a representative record. Include an update, a deletion or unpublish action, and a failure. Confirm whether the external system's identifiers can be stored reliably and how conflicts between editors and imported data will be handled.

Keep integration ownership explicit. The CMS vendor may support the API while a separate team owns the connector and another owns the destination system. A support agreement should make these boundaries workable when content fails to appear.

Can we leave with our content intact?

Evaluate export before committing. Request a sample containing structured fields, relationships, media references, publication state and relevant metadata. An export containing only rendered HTML may not preserve enough structure for a future migration.

• Which data can be exported, in what format?
• Are media files and their metadata included?
• Can identifiers and relationships be reconstructed?
• What access remains when a subscription or contract ends?

Attempt a small reconstruction outside the platform. You do not need to build a replacement CMS, but you should be able to explain how the exported records connect. Document any manual work or vendor assistance required.

The GOV.UK introduction to choosing technology includes considerations such as adaptability and control over data. Apply those concerns to the full implementation, including custom extensions and front-end code, rather than assessing only the core platform.

Who owns maintenance, security and support?

Write a responsibility list covering hosting, platform updates, extensions, custom code, backups, monitoring and incident response. Confirm the division in the proposed contracts. The responsibilities differ between service models, and marketing labels do not describe every boundary.

• Who evaluates and applies security updates?
• How are changes tested before production deployment?
• Who can restore service and content after a failure?
• What support is available when a custom integration breaks?

Review the extension strategy. Each dependency can introduce compatibility and maintenance work. Ask why an extension is needed, who maintains it and what the replacement plan would be if it became unsuitable. Prefer a small, justified set over a collection assembled without ownership.

Include your own organisation's duties. Staff still need to manage access, review content and report problems even when infrastructure is provided as a service. Budget for the people and routines that keep the CMS useful.

Can the migration preserve the meaning of the existing site?

Choose a sample containing ordinary pages, older articles, media, relationships and awkward legacy content. Ask the implementation team to migrate it into the proposed model. This reveals transformation work that a page count alone cannot estimate.

• Which old fields map directly, and which require editorial judgement?
• How will existing links and important URLs be preserved or redirected?
• Who checks migrated content for accuracy and accessibility?
• How will changes made during migration reach the final site?

Check relationships as well as individual pages. An article may import correctly while losing its author, related service or image credit. Decide which relationships are essential and how they will be validated across the full migration.

Agree how obsolete material is treated. Migrating everything can carry duplication and poor content into the new system. Removing material without review can discard useful information or break established journeys. Give content owners a defined review task and enough time to complete it.

Plan the publication transition. Editors need to know when changes pause, which environment contains the current version and how last-minute corrections are handled. A technical migration can succeed while the team accidentally publishes stale content if this ownership is unclear.

How will we record the trial results?

Use a shared evaluation sheet with the requirement, test scenario, observed result, implementation method and remaining question. Attach screenshots or sample exports where they provide useful evidence, while keeping the record concise enough to compare.

Mark custom development and extension dependencies explicitly. A demonstrated feature may be possible but absent from the quoted implementation. Ask the supplier to reconcile the trial findings with the proposed scope and operating cost.

Invite editors and technical maintainers to review the results together. A workflow that is pleasant to author but difficult to support creates a different trade-off from one that is robust but demands extensive training. Make that choice consciously, based on the organisation's priorities.

What does the total cost include?

Compare the same scope across shortlisted options. Include implementation, migration, content preparation, training, hosting or subscription, paid extensions, integration maintenance and support. Identify usage assumptions that affect the commercial model.

Ask what happens when the number of editors, sites, locales or API requests grows. Verify current terms directly during procurement. A low entry price is not a meaningful comparison if one option excludes capabilities that another includes in the proposed scope.

Keep mandatory requirements separate from scored preferences. A platform that fails a necessary access requirement should not win because it has many attractive minor features. For scored items, write the evidence beside the score and explain the weighting.

Finish with a short proof-of-fit exercise: migrate a representative content set, have real editors publish and revise it, test one important integration, and export the result. Choose the platform whose demonstrated workflow and ownership demands fit the organisation. That evidence is a stronger basis for commitment than the longest feature list.

Author

Abdullah Ahmed

With over 15 years of diverse experience spanning front-end and back-end development, UI/UX design, project management, integration, testing, and ongoing support for business applications, I specialize in transforming ideas into seamless digital solutions. I’m committed to leveraging my expertise to drive innovation and contribute meaningfully to the tech community.