The Definitive Guide to Selecting a Headless Content Management System

This blog post provides guidance for selecting a headless Content Management System (CMS). I assume that the reader has already committed to acquiring a headless CMS. In short, headless content management systems expose content through services but rely on external tools to convert that content to HTML for consumption by browsers. This post is not about the advantages of headless over tightly coupled and monolithic CMS architectures that include HTML generation engines. It is about factors to consider when selecting which headless CMS to employ.

The Early Days of CMS

I started working in the CMS industry in 2000, shortly after the first relevant products emerged. Over the years, I have investigated dozens of CMS products, both for several clients that engaged me specifically to help them select the optimal offering to meet their requirements, and while working for a leading CMS vendor for more than a decade, where I contributed to countless RFP responses and frequently evaluated competing offerings. This has left me with an overwhelming volume of criteria to consider in making a product selection and has also led me to some informed perspectives. There is no perfect CMS for every project, or that product would be a clear market leader.

Evaluating CMS options is much more complicated than determining whether each offering can address specific feature requirements. The number of CMS products available to evaluate is daunting, and the range of headless products is a very significant subset of that large number. Be prepared for a time-consuming process.

The Headless CMS Selection Process

Much of the guidance for selecting a headless CMS applies to selecting any CMS; some included criteria apply to any CMS selection process rather than just headless CMS. While architecturally it may be possible to consider the headless CMS “Content-as-a-Service” industry as a commodity, there are actually numerous differentiating factors between products. Especially in the fast-changing technology environment, this seems like a topic that can never be addressed fully. If you have suggestions for improving this article, please contact me (https://www.linkedin.com/in/johnwest3/).

In general, you can contact vendors through their websites. If you contact many vendors, you will likely be overwhelmed with responses, most of which will seem irrelevant to your questions. The most efficient approach, is typically, to request a demonstration, which often connects you with a salesperson, and use that opportunity to begin a dialog. Because sales may not always have the most accurate technical information, after creating the connection, I suggest that you request that a technical representative be involved in most communications.

Due to the incredible number of products and criteria to evaluate, rather than conducting an extensive review of each, I recommend coming up with a shortlist of products to consider by excluding any as soon as you identify an area where they do not meet the organization’s key objectives. As an obvious example, if a product is prohibitively expensive, it should not be under consideration. When interacting with each vendor, ask the most important questions first, and apply the same market razor for any of your fundamental criteria.

Base Criteria for Selecting a Headless CMS

Unfortunately, I’ve been working with headless CMS for long enough that I assume that every product includes what I would consider to be, “Least Common Denominator” functionality, such as GraphQL endpoints. Other than data modeling capabilities and the availability of a content tree being my most critical evaluation considerations, and support for preview being a key requirement, the following appear in no particular order, as the priority may vary by organization and even project.

• Data Modeling Capabilities: As a technologist, the data modeling capabilities of a CMS may be more important to me than any other criteria to evaluate. Data modeling capabilities include the variety of field types available for use in defining CMS content types, the complexity of structures allowed within a single content type (grouping, repeating, and nesting of fields), the ways that records can be embedded and referenced in other records, and the provision of a content tree, which is a fundamental consideration on its own.
• Content Tree: Most headless CMS do not provide a content tree that represents stored records in a hierarchy rather than flat lists with search options. A content tree has enough advantages for implementation architects, developers, and CMS users that the topic warrants its own blog post. Especially for websites, the availability of a content tree may be the second most important consideration in evaluating CMS products.
• Preview: Most customers want to preview their changes in the context of the website before publishing them to production. Different headless CMS vendors take different approaches, some of which may require the use of specific technologies. Evaluate available options to ensure the availability of a preview solution appropriate for your organization.
• SaaS: I believe that for most products and projects, the Software-as-a-Service (SaaS) hosting model allows customers to achieve the greatest Return on Investment (ROI) and lowest Total Cost of Ownership (TCO) for a headless CMS product. While there are always tradeoffs, the advantages of SaaS deserve their own blog post.
• Price: The price of a product does not always indicate its capabilities. Determine your budget for the CMS and exclude products that are not within range. Unfortunately, each CMS vendor may use different criteria to price their products, and some make it very difficult to get accurate estimates in advance. Do your best to get clear pricing commitments before thoroughly reviewing any product.
• Workflow: Most CMS include workflow capabilities that you can use to control publication processes, such as requiring approval checkpoints before content reaches the public website and other delivery channels. While some level of review is important, based on significant experience, I have trouble recommending significant investment in CMS workflow. Solutions that invest too much in workflow often stifle and frustrate users with cumbersome processes that do not add value and fail to achieve their intentions, especially as users find workarounds or approve changes without sufficient review. I find that manual processes often work better than attempting to automate every possibility. Organizations that must enforce complex workflow may be better served by using enterprise workflow engines operating outside of or in conjunction with the CMS.
• Back-End Technologies: While headless CMS theoretically works as a black box, where developers should not need any knowledge of its internals, a review of the back-end components, architecture, and technologies is still a worthwhile investment, and can be seen as both a learning opportunity for the architects involved in the evaluation and a form of due diligence to ensure appropriate architectural practices. While the best practice may be to employ technologies independent of the vendor’s, convergence can be advantageous: certain support issues are addressed most efficiently when the customer and the vendor use the same development tools.
• Front-End Technologies: There are two areas in which to evaluate front-end technologies used by the vendor. The first is the front-end technologies used in the CMS UI, especially for customers that expect to extend that UI with custom field types or other features. The second is front-end technologies used in starter kits available for accelerating solution implementations. If the customer is competent with the technologies used by the vendor, it will be easier, faster, and less expensive to implement the solution, and exchanges with technical support will be more efficient.
• Stability: An enterprise should invest in vendors that demonstrate product, market, and financial stability in several forms. While new features should appear frequently, the product should not undergo constant architectural shifts. The vendor should have an impressive and growing customer roster and strong customer retention and should be well-capitalized and profitable, or at least have a clear path to profitability.
• Rich Text Editor: While we all know that it is best to separate content from presentation, we also know that a rich text editor is always important. The rich text editor should have features appropriate for project requirements, and it should be possible to disable features that the organization does not want used. Some vendors may store rich text as HTML, while others may use proprietary JSON formats (some also provide markdown editors). Storage as HTML can have disadvantages for reusing content on channels other than the web, while JSON requires vendor-specific code to transform rich text to HTML for the web, which reduces performance and increases vendor lock-in. As HTML is the most common use case, and as it is possible to extend HTML with custom elements and attributes, my general preference is for storage as HTML. For organizations that need to use rich text for channels that do not support HTML, JSON may be preferable.
• Integrations: Most CMS vendors provide various integrations with external products such as commerce platforms, marketing automation solutions, and analytics engines. The number of integrations available from the CMS vendor can indicate its level of market adoption, but beware that not every integration is as complete and robust as you might expect. If an integration available from a vendor may influence your product selection, evaluate that integration carefully before committing to that vendor.
• Optional Features: Consider the range of optional features available, such as a library of custom field types to augment those provided out of the box.
• Community: The number of developers using a tool is strong evidence of its prevalence in the market. A larger developer community should make it easier and potentially less expensive to hire staff experienced with a specific product. Optimally, the vendor should provide a dedicated site for the community to share knowledge, and that community should be active.
• Performance: Consider the performance of the vendor’s solution, including the CMS user interface, service Application Programming Interfaces (APIs), and the vendor’s Content Delivery Network (CDN) for serving media such as images. While the implementation of the vendor’s software is a fundamental factor, performance can also depend on the location of the vendor’s hosting facilities and their proximity to consuming applications such as browsers. Different vendors have different capabilities for geographical distribution.
• Scalability: Related to performance is scalability; ensure that the CMS vendor can increase the capacity of your solution to meet peak expected traffic demands.
• Search UI: Especially for solutions that do not provide a content tree, search capabilities within the CMS UI can be critical for users to efficiently locate content. The search UI should expose necessary capabilities in an intuitive manner rather than requiring the use of cryptic features for filtering and otherwise.
• Search CD: Some vendors may provide a content delivery service APIs that allow searching or querying for records in the CMS. If this is the case, then it may be worth asking whether these facilities allow searching across multiple content types or only within a single content type.
• User Interface: The CMS user interface should be appealing, highly intuitive to use, and extensible to incorporate features needed by the organization.
• Media Manipulation: You can direct some CMS to manipulate media automatically on the server, such as resizing images based on query string parameters in their URLs. If you are certain that your project would employ such features, then consider these options in your evaluation process.
• Documentation, Starter Kits, and Support: While the documentation and example solutions should allow you to implement your solution with minimal interactive guidance, it is still important to evaluate the support offerings provided by the vendor, such as how quickly they respond to support cases and the quality of those responses.
• Intangibles: As you work with the vendors, evaluate intangibles such as responsiveness, friendliness, helpfulness, knowledgeability, and especially honesty. Ask hard questions, such as who the vendor considers to be their most significant competitors, and how they and those vendors differentiate from each other. Vendors should sometimes respond that a competitor has a specific advantage or that the product cannot inherently meet certain expectations, in which case they should work to identify a solution.
• Vendor Lock-In: One goal of headless CMS is to decouple the front-end content delivery technology from the back-end content management technology. Implementing a front-end solution that depends heavily on the vendor’s Software Development Kit (SDK) or JSON structures works against this objective. Simply invoking a vendor’s service API from front-end code is a form of lock-in. If you cannot consider architectural approaches to mitigate these concerns, such as flattening data from the CMS into a search index for the front-end to consume, then evaluate how significantly your front-end code must depend on the vendor’s SDK, APIs, and JSON formats.
• Dedicated and On-Prem: Enterprises that require hosting on dedicated instances or in their own private clouds rather than shared infrastructure should only evaluate vendors that can meet these needs.
• SDKs: While it is possible to invoke service APIs from any technology, vendors typically provide SDKs to facilitate implementations with specific programming languages, especially JavaScript. To mitigate vendor lock-in, you may want to implement your own SDK. If you plan to use a vendor’s SDK, ensure that the vendor actively maintains that component for the technology that you use. For example, a vendor may provide a .NET SDK, but because relatively few headless CMS customers use .NET, that SDK may not receive the same amount of attention as its JavaScript SDK.
• Synchronization API: All headless CMS vendors should provide service APIs that allow selecting one or more records. Some vendors provide synchronization APIs to support complete data exports and updates, which can be important depending on your architecture, such as to implement efficient strategies to build and update search indexes from content in the CMS.
• Link Management: Records in the CMS can contain references to other records. The CMS may store the unique identifier of the referenced record, or it may store the URL of the referenced record. Rich text fields often store the URL rather than the GUID. The result can be broken links, as nothing validates that the URL is the current URL for the referenced record, for which the URL may have changed after the original URL appeared in the rich text field value. References stored as either IDs or URLs can break when the referenced record has been deleted. Optimally, the CMS addresses these concerns by always storing the ID of the referenced record and by prompting users to update referencing content when they delete a referenced record.
• Internationalization: If your solution needs to manage content in multiple languages or is likely to have such a requirement in the future, evaluate how the CMS manages internationalization for storage, translation, and publication workflow.
• Security: If you require the solution to use a specific mechanism to authenticate CMS users before they can manage content, evaluate how easily the vendor can support the authentication mechanism that you require.

Final Remarks

Selecting the right Headless CMS requires careful consideration of numerous criteria that vary by organization and importance. Almost any selection will involve some trade-offs, challenges, and compromises. It is often advisable to implement a proof-of-concept to evaluate key challenges. Rather than focusing primarily on implementing the front end of the website, such an effort should include other key criteria such as publishing workflow, CMS user authentication, and internationalization. CMS selection can have long-lasting effects; take the time to thoroughly evaluate your options and choose the option that best meets your specific needs