QU Quiet Publish Lab
Platform Planning

How to Choose a CMS: 7 Questions Before You Commit

Quiet Publish Lab · Updated 2026-07-19 · 4 min read
How to Choose a CMS: 7 Questions Before You Commit
SummaryChoose a CMS by defining your content model, publishing roles, approval workflow, delivery channels, required integrations, editor responsibilities, operating costs, and exit needs. Test every finalist with the same representative tasks and restricted user accounts. Score demonstrated behavior rather than feature claims, include migration and maintenance work in the comparison, and reject any option whose security, backup, export, or ownership model remains unclear.
Contents

Choose the workflow before choosing the software

To choose a CMS, document who publishes, which content types exist, what approvals are required, how pages must be delivered, and what the team can maintain. Then test finalists with the same representative publishing tasks. A polished demo answers “Can the presenter make this look easy?” Your evaluation must answer “Can our team run this on an inconvenient Tuesday?”

Start in platform planning with the seven questions below. Write each answer as a requirement you can verify.

1. What content are you actually managing?

List distinct content types—articles, landing pages, profiles, events, documentation, products, or something else—and the fields each requires. Separate reusable data from free-form page layout.

A system that handles thirty simple pages may struggle with thousands of related records, multiple languages, complex revisions, or structured reuse. “We publish content” is not yet a content model; it is the software equivalent of telling a builder you enjoy rooms.

2. Who creates, reviews, publishes, and corrects it?

Map roles and the transitions between them. Can an author save a draft without publishing? Can an editor preview it? Who can change navigation, templates, or permissions? How are urgent corrections handled?

Test these jobs with realistic accounts. Administrator access can make every workflow appear wonderfully flexible because it quietly removes the workflow.

3. How must the content reach readers?

Decide whether the CMS renders the website itself, supplies content through an API, or supports both. Identify every required destination: web pages, apps, feeds, email, on-site search, syndication, or printed outputs.

Architecture labels are less important than delivery behavior. Confirm preview, caching, image handling, URL control, and failure behavior in a representative environment.

4. Which integrations are truly required?

List authentication, analytics, search, translation, customer data, forms, media storage, and deployment systems that must connect. Mark each integration as essential, useful, or optional.

Verify how the connection works, who maintains it, what data moves, and what happens when either side changes. A logo on an integrations page is an invitation to investigate, not proof that your exact workflow is covered.

5. What must editors do without developers?

Ask editors to create, revise, schedule, unpublish, restore, and find content. Test validation messages, bulk changes, media reuse, keyboard operation, and preview across required templates.

The goal is not limitless control. It is safe control: enough flexibility for routine work, with guardrails that prevent accidental design and data damage.

6. What will ownership cost over time?

Consider licensing, hosting, implementation, migration, training, extensions, support, security work, upgrades, monitoring, backups, and internal staff time. Do not invent one five-year number from an early sales conversation.

Request comparable assumptions from every finalist and identify which costs scale with users, traffic, environments, storage, or features. Document exit costs too; the least romantic feature of a CMS is how it returns your content.

7. How will you leave or recover?

Confirm export formats, API access, database ownership where applicable, media retrieval, backup frequency, restore testing, audit logs, and deletion procedures. Ask how a failed deployment or compromised account is contained and recovered.

Before committing, sketch the CMS content migration checklist in reverse. If you cannot explain how content would enter, map, verify, and eventually leave, the selection is not finished. The migration workflows section helps expose that work before a contract turns it into archaeology.

Score evidence, not enthusiasm

Build a table with requirements as rows and the same evidence scale for every candidate:

Score Meaning
0 Requirement not supported
1 Claimed, but not demonstrated
2 Demonstrated with limits or extra work
3 Demonstrated in the target workflow

Weight only genuinely important requirements, record caveats beside each score, and preserve notes from the test. The winning CMS is not the one with the longest feature list. It is the one whose verified tradeoffs your team can operate, secure, fund, and eventually change.

FAQ

What is the most important factor when choosing a CMS?

Fit with the required publishing workflow is the central factor. The system must support your content types, roles, approvals, delivery channels, security controls, and maintenance capacity together. No single feature or architecture label settles that question. Test representative tasks with the people who will perform them and document where custom work, extensions, or manual steps are required.

Should a small team choose a headless CMS?

Only when its delivery needs and technical capacity justify the separation. A headless setup can support content reuse across channels, but it also requires a separate presentation layer, preview strategy, deployment process, and ongoing engineering ownership. Compare that work with an integrated system using the same requirements. ‘Modern’ is not a substitute for a staffed operating model.

How should I compare CMS pricing?

Compare total ownership assumptions rather than one advertised fee. Include licensing, hosting, implementation, migration, training, support, extensions, security work, upgrades, monitoring, backups, and staff time. Identify which costs change with users, traffic, storage, features, or environments. Vendor terms and prices can change, so verify current written details before making a procurement decision.

Who should be involved in CMS selection?

Include representatives of the people who create, edit, approve, design, develop, secure, analyze, support, procure, and govern content. Not every person needs every meeting, but each affected workflow needs a knowledgeable voice and a realistic test. Reader needs, accessibility, privacy, and operational support should be requirements, not late-stage comments after the platform has already won.

What should I test in a CMS demo?

Test creating and revising real content types, previewing, approvals, scheduling, unpublishing, restoring, searching, media reuse, permissions, validation, and any required integration. Use non-administrator accounts and representative content, including awkward edge cases. Ask the vendor to show limitations and recovery behavior. A scripted happy path is useful orientation, but it is not acceptance testing.