# Headless CMS evaluation scorecard

Bejamas • September 8, 2026

Use this worksheet with the same real content, editors, and publishing tasks for every candidate, including your current platform. This is a decision aid, not a vendor rating or a compliance assessment.

## Evaluation brief

- Decision owner:
- Editors participating:
- Sites, brands, and languages:
- Content types and approximate volumes:
- Required integrations:
- Publishing tasks currently blocked:
- Requirements that must pass:
- Candidate, quoted plan, region, and add-ons:
- Evidence date and implementation owner:

## Separate required conditions from scored preferences

A failed required condition prevents selection even if the weighted score is high. Mark an untested requirement "unknown" rather than treating it as a pass. Require a demonstrated solution, or a specifically scoped and accepted implementation plan, before closing an unknown.

For scored preferences, assign weights totaling 100 before vendor demos. Use 0 for a demonstrated failure, 1 for a weak fit with substantial accepted work, 2 for an acceptable fit with defined work, and 3 for a demonstrated fit in the proposed configuration. Calculate each contribution as weight × score ÷ 3. Report the total only when every scored row has evidence.

| Criterion                                                                                 | Required condition? | Weight | Score 0–3 or unknown | Evidence and date | Required implementation | Owner |
| ----------------------------------------------------------------------------------------- | ------------------- | ------ | -------------------- | ----------------- | ----------------------- | ----- |
| Editors can compose and preview the campaign                                              |                     |        |                      |                   |                         |       |
| Approval and publishing permissions match responsibilities                                |                     |        |                      |                   |                         |       |
| Markets can translate, override, and publish as required                                  |                     |        |                      |                   |                         |       |
| Shared content updates reach every intended destination                                   |                     |        |                      |                   |                         |       |
| Integrations meet the required data and update behavior                                   |                     |        |                      |                   |                         |       |
| Security, data-location, and support requirements are accepted by their owners            |                     |        |                      |                   |                         |       |
| Migration sample preserves content relationships, metadata, and working URLs or redirects |                     |        |                      |                   |                         |       |
| Platform, implementation, and operating costs fit the agreed scope                        |                     |        |                      |                   |                         |       |
| The website has a named maintenance and publishing-support owner                          |                     |        |                      |                   |                         |       |

## Proof-of-concept tasks

1. Build a campaign from approved components, then introduce a layout the model does not yet support. Record the developer work required.
2. Reuse a product record or customer story on two pages. Edit it and inspect both previews.
3. Prepare a translated campaign with a missing translation and a market-specific exception. Confirm fallback and independent publishing behavior.
4. Follow the real approval chain. Verify that each participant can perform only their intended actions.
5. Import representative legacy content with references, rich text, assets, and metadata. Check the rendered output and changed URLs.
6. Simulate a failed publishing update. Identify how the team detects it and who restores the intended result.

## Cost comparison

Use the same period, content volumes, usage assumptions, languages, and team size for each candidate.

| Category                                        | Initial cost | Recurring cost and period | Assumptions / exclusions | Owner |
| ----------------------------------------------- | ------------ | ------------------------- | ------------------------ | ----- |
| CMS plan, capacity, seats, locales, and add-ons |              |                           |                          |       |
| Design, content model, and components           |              |                           |                          |       |
| Preview and integrations                        |              |                           |                          |       |
| Migration, verification, and training           |              |                           |                          |       |
| Hosting, monitoring, and maintenance            |              |                           |                          |       |
| Next market, brand, or content type             |              |                           |                          |       |

## Decision record

- Required conditions passed:
- Unknowns and how they will be resolved:
- Weighted score with evidence:
- Accepted implementation work and cost:
- Reasons for selecting or rejecting this candidate:
- Case for improving the current platform:
- Decision owner and date:

Guide: https://bejamas.com/stack/cms/how-to-choose-a-headless-cms-for-enterprise