How to choose a headless CMS (when the stakes are real)

TL;DR

For anyone assembling a headless CMS shortlist with a security review, several markets, and an incumbent platform attached:

• “Best headless CMS” is the wrong question. Nearly every page ranking for it is a vendor or a reseller arguing its own book, and the rankings compare API features that stopped differentiating years ago. Every serious platform has a competent API. That is the entry ticket, not the decision.
• Four criteria actually decide a shortlist: governance (roles, workflows, audit trails), procurement (security review, SLAs, data residency, total cost of ownership), multi-market and multi-brand publishing, and the migration path off the platform you run today.
• “Enterprise CMS” describes requirements, not headcount. Enforced SSO, roles that match your org chart, audit trails, contractual SLAs, residency options. Score the requirements you actually have, not the tier a vendor sells.
• Total cost has three layers, and the license is often the smallest. Implementation and long-term operation decide the business case; the license is merely the number that appears on the quote.
• Your current platform is a selection criterion. What it takes to get content, metadata, and rankings out of Sitecore, AEM, Drupal, or WordPress shapes which destination makes sense, and whether the move is worth making at all.
• We implement Sanity, Storyblok, and Contentful and resell none of them. This framework is the one we apply in paid platform audits, published.

Why the ranked lists keep choosing wrong

Search for the best headless CMS and read the top results with one question in mind: who published this, and what do they sell? Almost without exception the answer is a CMS vendor ranking itself first, or an implementation partner ranking the platform it resells. That does not make every word false. It makes every ranking unfalsifiable, because the criteria were chosen after the winner.

The listicle format also flatters the wrong criteria. API flexibility, SDK coverage, and developer experience were genuine differentiators once. Today, any platform that has survived in this market clears that bar. Meanwhile the things that actually sink replatforming projects rarely appear on a comparison grid at all: a governance model that fights your org chart, a procurement review that stalls for a quarter, a localization model that cannot express how your markets really work, and a migration that was scoped as a line item instead of the project’s hardest part.

This guide is for the person accountable when one of those things goes wrong: a marketing or digital leader responsible for a web estate spanning brands, markets, or business units, with existing traffic to protect and a security team that will review whatever gets picked. If you are a developer evaluating query languages and SDKs, our platform pages go deep on each system. This page covers the rest of the decision, which in our experience is most of it.

One note on the word everyone types into the search box. When buyers say enterprise CMS, headcount is not really the point. The label stands for a set of requirements: single sign-on enforced across every account, roles precise enough to mirror how responsibility is actually divided, audit trails a compliance officer can use, contractual SLAs, data residency options, and the ability to run many markets on one platform without forking it. Plenty of 200-person organizations have every one of those requirements. Some far larger ones have none. Score requirements, not tiers.

Criterion 1: governance, or who can publish what, and who signed it off

Governance is the criterion that looks boring in a demo and decides whether the platform survives contact with your organization. It has three layers, and vendors are strong at different ones.

Roles and permissions. The test is not whether the platform has roles. Everything has roles. The test is whether the roles can be scoped the way your responsibility is actually divided: by brand, by market, by section of the site, by content type. A market editor in Madrid should be able to publish a local campaign page and should not be able to touch the global navigation. If expressing that requires a workaround, you will be living with that workaround for years.

Workflows and approval. Regulated content, legal review, brand sign-off: if any publish on your estate needs a second pair of eyes, the workflow has to exist in the CMS, not in a Slack thread beside it. Ask the vendor to recreate your gnarliest real approval chain live in the session, with your steps and your roles. A workflow feature that cannot model your actual workflow is a checkbox, not a capability.

Audit and change control. Who changed this page, when, what did it say before, and can we restore it? For most teams this is insurance. For anyone operating under compliance obligations it is a requirement with an owner and an annual review. Check how far the audit log reaches: content changes, yes, but also role changes, content model changes, and API token issuance.

Among the platforms we implement, Contentful has the most governance built in: granular roles, environments, and validations designed for large teams. Sanity can express nearly any governance model, but as something your implementation defines in code rather than switches on. Storyblok handles folder-level permissions and approval pipelines well in an interface editors actually enjoy. All three pass this criterion; what differs is how much of the model you configure versus build, and that difference belongs in your implementation budget, not in a surprise.

Criterion 2: procurement, or pass the review before you fall in love

More shortlists die in security review than in technical evaluation, and they die slowly. The way to avoid losing a quarter is to run procurement’s questions in parallel with the evaluation instead of after it.

The security review. Get the questionnaire from your security team on day one and send it to every vendor on the shortlist. The recurring items: SOC 2 Type II report or ISO 27001 certificate, SSO via SAML or OIDC with SCIM provisioning, penetration test summaries, breach notification terms, and a current sub-processor list. Watch for the SSO price gate: on several platforms, enforced single sign-on lives in the top tier, which can double the license before the evaluation is over. Find that out in week one, not at contract.

Data residency. For European organizations this is frequently the decisive question. Where is content stored, which cloud does the vendor run on, can you choose an EU region, and what data leaves it? The honest answers vary widely between platforms and change over time, so demand them in writing for the specific plan you are buying. If your requirement is stricter than a hosting region, the shape of the answer changes: self-hosted and open-source options trade vendor convenience for control, a trade we cover in SaaS vs open source headless CMS.

SLAs and exit terms. Uptime commitments with actual remedies, support response times for the tier you are buying, and, just as important, the exit: what does a full export contain, in what format, and does anything about the contract or the architecture make leaving harder than arriving? A platform you cannot leave is a platform you cannot negotiate with at renewal.

Total cost of ownership. Price the decision over three years, in three layers:

That third layer is where the case for the move is won or lost, because it is mostly people. When Bennetts consolidated three sites off a legacy Sitecore install onto one headless platform, total cost of ownership dropped 70% against the documented Sitecore baseline, and the license line was only part of it: the standing dependency on specialist developers for routine publishing ended too. That is the shape of the calculation to run for your own estate, with your own numbers.

Criterion 3: multi-market and multi-brand publishing

If your estate spans languages, markets, or brands, this criterion should carry the most weight, because it is the hardest thing to retrofit. Platforms differ more here than anywhere else, and the differences hide in the data model.

How localization is modeled. Some platforms localize at the field level: one document, many languages, translations attached to each field. Others localize at the folder or space level: each market a separate tree that can diverge. Neither is better in the abstract. Field-level suits estates where markets are translations of one canonical site; tree-level suits estates where markets genuinely differ in structure and campaign calendar. Pick the model that matches your operating reality, because editors will fight the wrong one daily.

Fallbacks and divergence. What happens when the German translation of a new page does not exist yet: does the market show English, show nothing, or block the publish? Can a market override one section of a global page without forking the whole page? These unglamorous questions are the actual texture of multi-market operations, and demos skip them unless you ask.

Brands on one platform. Multi-brand is governance plus localization at once: shared components and content types where the brands overlap, separation where they must not touch, and permissions that keep brand teams out of each other’s spaces. The payoff for getting it right is a single platform your whole organization operates instead of a portfolio of snowflake sites, an argument we make at length in Multilaunch: how multi-brand companies win online.

The proof that this works is operational, not architectural. Van Raam runs its site in four languages with one team managing content from one place, with more locales cheap to add. Bennetts runs what used to be three separately maintained sites as one platform. The evaluation question for your shortlist is concrete: ask each vendor to walk through publishing one campaign to three markets, with one market opting out and one market overriding an image, and watch how many steps it takes.

Criterion 4: the migration path off the incumbent

No ranking scores this, because it is not a property of the destination. But the platform you are leaving shapes the entire project: the cost, the timeline, the risk, and sometimes the right answer.

Off Sitecore or AEM: the work is untangling the estate from a suite. Content export tooling is thin, years of implementation decisions live in the platform rather than in documentation, and the licensing clock keeps running while you migrate. The decision usually starts one level higher: is the DXP still doing a job worth its cost? Our Sitecore and AEM pages take that question seriously, and the migration itself is its own service for a reason.

Off Drupal: the content is usually well structured, which is the good news; the pressure is version end-of-life and the shrinking pool of people who want to maintain the estate. Structured content maps comparatively cleanly onto a headless model.

Off WordPress: the content exports easily and the SEO configuration does not. Years of plugin-managed metadata, redirects, and schema hide in places a content export does not reach. There is also a path most rankings ignore: keeping WordPress as the editorial backend behind a modern front end. When Backlinko, a business whose revenue is organic search, replatformed, that is what it chose: headless WordPress with Next.js in front, migrated in two months.

Whatever the incumbent, two things about the move are non-negotiable. First, the migration plan is part of the platform evaluation, not a follow-up project: an estimate of content inventory, URL count, redirect map, and editorial retraining belongs in the same document as the license quote. Second, existing search equity has to be treated as an asset under transfer. Rankings are attached to URLs, and a replatform moves all of them; the controls that protect them are laid out in our replatform SEO playbook, and the CMS-specific risks in Headless CMS SEO: what actually breaks.

This is also where we can point at evidence instead of assurances. Danone’s Alpro came off Adobe Experience Manager onto Contentful and came out of its rebuild with marketers publishing without developers and SEO metrics up 17.6%. Descope migrated a high-traffic site onto Contentful with SEO and content integrity preserved through the move. And the incumbent’s exit cost cuts both ways: whichever platform you choose next, ask what it takes to get everything out of it, because portability is cheaper to buy than to retrofit.

Where Sanity, Storyblok, and Contentful actually differ

Since every serious platform clears the API bar, the honest differences are about how each one distributes the work of meeting the four criteria. We implement all three in production; this is the short version of what we tell clients in an audit.

• Sanity treats content as structured data and the editing environment as something your team defines in code. Maximum expressiveness: any governance model, any localization scheme, any editorial interface can be built. The corollary is that they have to be built, so Sanity rewards teams with a real implementation partner or in-house engineering ownership, and it is the strongest choice when content feeds more surfaces than one website.
• Storyblok puts the visual editor first: editors compose pages from components and see what they are publishing. Folder-based permissions, approval pipelines, and built-in translation workflows make it a strong fit for marketing-led, multi-locale estates. The discipline it demands is on the modeling side, keeping components structured as the estate grows rather than letting pages become one-off assemblies.
• Contentful is the platform procurement departments already know: mature governance, environments, granular roles, and the compliance posture large reviews expect. It prices accordingly, and the editing experience is more form than canvas, so editor buy-in is worth testing early. Strongest when governance requirements lead the criteria list.

These three are not the whole market. DatoCMS punches above its weight for multi-locale estates (it is what Bennetts and Van Raam run on), and our platform index covers the wider field with the same stay-or-go honesty. For a deeper cut on the editor-experience differences, see our comparison of Sanity, Storyblok, and DatoCMS.

Running the evaluation: six steps, not six months

The process that produces a defensible decision is not elaborate. It is just easy to skip under time pressure, which is how organizations end up choosing on demo charisma.

1. Weight the four criteria for your estate, in writing. A regulated single-market business weights governance and procurement. A consumer brand in twelve countries weights multi-market publishing. Write down the weighting before any demo, because demos are designed to reorder your priorities.
2. Shortlist two or three platforms, not six. Use the weighting to disqualify, and record why each excluded platform was excluded. That document is worth more than it seems: it is what you show the stakeholder who asks “did we consider X?” a year later.
3. Script the demos around your content. Send each vendor the same brief drawn from your real estate: your trickiest content type, your real approval chain, your three-market publishing scenario. Refuse the standard demo. How a vendor handles your script is itself evaluation data.
4. Run the security review in parallel. Questionnaires to all finalists in week one. This is the step that protects the timeline.
5. Pay for a proof of concept. Two to four weeks, real content model, one locale flow, your editors doing the clicking. A paid PoC with your actual content answers questions no feature matrix can, and it converts directly into the implementation if the platform passes.
6. Score total cost over three years, all three layers. License, implementation, operation, on your publishing volumes and your team. Then have someone argue the case for staying put, seriously, before you sign.

The scorecard for the demo and PoC stages:

When the answer is not a new CMS

A selection framework is only trustworthy if it can return “none of the above,” so here is ours doing that.

Stay where you are if the strongest argument anyone can produce is that headless is more modern. Modern is not a requirement; the four criteria are, and if your current platform meets them, the migration budget is better spent elsewhere. Stay if your editors are productive and your governance works, even if developers find the platform unfashionable. And postpone the move if there is no engineering ownership waiting on the other side, because a headless platform without an owner decays into the same bottleneck you left, minus the plugins. We wrote the honest version of this argument, including when the answer is that a rebuild does not require touching your CMS at all, in Headless CMS SEO.

The cases that do justify the move are operating problems, not fashion: brands and markets multiplying faster than the platform can absorb, editors queueing behind developer tickets for routine publishing, license costs out of proportion to the job being done, content locked in a system it cannot leave. If several of those describe your estate, the criteria above will not just pick a platform. They will tell you what the platform has to fix.

Common questions

Which headless CMS is best?

There is no ranking answer that survives contact with real requirements, and pages that offer one are nearly always selling something on the list. Among the platforms we implement: Sanity when content is structured data feeding many surfaces and engineering ownership exists, Storyblok when marketing-led teams publish across locales and want a visual editor, Contentful when governance and compliance requirements lead. The four criteria in this guide, weighted for your estate, decide it faster than any listicle.

What makes a CMS an “enterprise” CMS?

Requirements, not company size: enforced single sign-on, roles that mirror the org chart, audit trails, contractual SLAs and support, data residency options, and multi-market publishing on one platform. A CMS meets the bar or it does not, whatever tier name is on the pricing page, and organizations well under a thousand people frequently need every item on that list.

How much does an enterprise headless CMS cost?

License quotes for governance-tier plans typically run from tens of thousands of dollars a year into six figures for large estates, but the license is one layer of three. Implementation, including the migration, routinely exceeds the first year of license on estates of any size, and long-term operation, above all who can publish without a developer, decides the multi-year number. Price all three layers over three years before comparing anything.

How long does replatforming onto a headless CMS take?

A focused single-site migration can land in around two months, which is what Backlinko’s move to headless WordPress and Next.js took. Multi-brand, multi-market consolidations run longer because content modeling, redirects across the full URL inventory, and editorial retraining are real workstreams. Whatever the estimate, insist that the migration plan arrives with the platform recommendation, not after it.

Do we have to leave WordPress to go headless?

No. Keeping WordPress as the editorial backend behind a modern front end preserves your editors’ workflow while replacing the delivery layer, and it is a credible destination when the editorial team is genuinely productive in WordPress. The trade-off is that plugin-managed SEO output has to be carried into the new front end deliberately; our headless WordPress page covers when this path beats a full platform change.