Petal

How to Compare CMS Options.

What factors are most critical when choosing the right CMS solution, and which choice will be in the best long-term interests of your content operations? This guide provides a non-technical introduction to significant factors in content management that will influence the outcomes your organization can achieve.

Why this guide?

Your choice of a content management system (CMS) will affect everyone who relies on content for business results. Despite the importance of CMSs, it can be difficult to know what elements influence the outcomes that they can deliver.

Understand the factors that contribute to success. While the individual features of a CMS each play a role, how these features work together—or not—will determine what outcomes you can achieve. Many organizations make the mistake of focusing on CMS features individually instead of examining how they are designed to work together as a platform.

Content management systems have earned a reputation—not undeserved—for being difficult to navigate. This guide provides a non-technical introduction to significant factors in content management that will influence the outcomes your organization can achieve.

Clarify your decision parameters. Once you get past the jumble of CMS features and jargon, what factors are most critical, and which choice will be in the best long-term interests of your content operations? This guide will explore the factors necessary to ensure:

  • Your content is maintainable and future-ready
  • Your CMS setup promotes operational efficiency
  • Your setup can adapt to evolving needs

This guide will explain the differences in CMS product categories so you can:

  • Appreciate how features that are used or implemented will influence outcomes 
  • Look beyond the presence of individual features to see how they interact 
  • Understand the capabilities necessary to adapt to evolving requirements

Prepare to transform your content operations

Think about how content fits in the digital transformation of your organization. Most professionals believe that content operations should become more connected and unified. Enterprises need to respond to a changing competitive environment.

IssueBeforeNow
ScalabilityTeams worked independently on specific websites and apps with little coordination.Enterprises need to address and coordinate a growing range of diverse content. They can’t afford for their content operations to be siloed.
OmnichannelMost content was intended for websites.Organizations need to support a range of channels.
Ease of useThe choice was between simple tools that did little but required no training or complex tools that had more capabilities but required extensive training.Organizations expect ease of use without sacrificing sophistication.
AgilityOrganizations expected time-consuming workflows and difficulty when making operational changes.Improving the speed of publishing and avoiding time-intensive handovers are priorities.
Adaptability to future needsOld CMSs would need to be replaced every few years because they weren’t easily upgraded.Cloud-based platforms can continuously upgrade. Enterprises want to be able to add enhancements to take advantage of the latest and best technologies, quickly and without disruption.
DependabilityBecause CMSs would routinely need to be replaced (re-platformed), the content would also be reworked or replaced to fit website redesigns.Organizations cannot afford the disruption of having to redo content when making design or technology changes.

Each of these issues suggests a need for greater flexibility in how enterprises work with content. But flexibility isn’t a discrete feature of a CMS. It depends on many factors, as we will see.

The landscape: Content management categories

The backbone of content operations is a content management system (CMS), which supplies a range of capabilities to support the creation, management, and delivery of content. CMSs come in many configurations, which can sometimes make them difficult to compare.

Content management systems can be divided into three broad categories:

  1. Page-oriented CMSs designed to output HTML web pages
  2. Modified page-oriented CMSs that let publishers remove or switch off functionality used to generate the display of pages (we’ll refer to these as “head-optional CMSs”—because the use of internal functionality that presents the content, known as the “head,” is optional)
  3. Headless CMSs, which can deliver all kinds of digital content to any channel, but unlike other CMSs, don’t render the content in a user interface for a specific channel such as a website (we’ll refer to them as “headless-native CMSs” because the body of content is managed separately from the how that content is presented in user interfaces)
A group of five young people working on content for a website

Table: How categories decide configuration

CMS categoryOpinion about content management settingsConfiguration 
Page-orientedPrescriptive: choices predefinedFixed
Head-optionalOptions as exceptionsPartly flexible
Headless-nativeOpen choice: publisher chooses among many optionsFlexible

CMSs differ in whether features are fixed or flexible. Many CMSs seem to offer equivalent features, but on closer look, they vary as to whether the feature is fixed or flexible. While it may be possible to modify a fixed feature, it will require more effort than if the features provided or that can be added are flexible by design.

Look beyond the features. Capabilities are more than a checklist of features. The configuration of your CMS will determine whether the product will meet your needs. CMS products will vary in how readily they can be adapted to your organization’s specific requirements. Many CMSs permit a degree of customization of default settings or workarounds of them, but certain CMSs allow for a much higher degree of configuration.

Page-oriented CMSs

In the past, most CMSs were page-oriented, designed to output HTML for web pages. Page-oriented CMSs encompass a range of products, such as:

  • Web CMSs (WCMSs)
  • Digital Experience Platforms (DXPs)
  • Component CMSs (CCMSs) designed to publish XML documents to websites

While these CMS products are often considered distinct categories, they share a number of common traits.

Six people sitting around a table and working on laptops

Basic features of page-oriented CMSs

Even though page-oriented CMSs can differ widely in their specific features, they embrace a similar approach to managing content. They typically positioned themselves as “all-in-one” solutions that will handle everything a web publisher would need to do. The vendor has decided on most settings, defining generic functionality that it believes is sufficient for most organizations. These CMSs aren’t designed to support flexible configuration and can be difficult or expensive to modify.

A focus on pages and documents. As reflected in its name, a page-oriented CMS is geared to building web pages and articles. This orientation influences how the content gets created and how it is delivered.

The output destination shapes how the content is composed. In a page-oriented CMS, layout templates strongly influence how the content must be created and how it can be used. Authors create content for a specific screen component or part of a web page.

The CMS vendor supplies predefined page types. The CMS vendor supplies default page structures used to generate the output. If the default page types don’t match what the publisher wants to express, the publisher must modify existing pages or custom-develop new page types. Flexibility may be limited.

Website oriented. The page-oriented CMS is not designed to support diverse publishing scenarios. The CMS is set up to publish content to the web channel. If customers need to access content outside of a web browser (for example, in a mobile app or a chatbot), the publisher will need to use other tools or else needs to customize the delivery capabilities provided by the CMS. For example, with one CMS, you may need to create a “custom REST endpoint” to deliver your content to a mobile app (we’ll discuss APIs and their significance shortly). With another one, you may get REST API functionality that would allow you to deliver content to non-website channels, but it’s hard to tailor your content for other channels because the CMS’s authoring UI is based on predefined page types and is geared to building web pages. These CMSs need major revamping or overhauling to support publishing to non-website channels.

Modified page-oriented CMSs that have been updated to be “head-optional”

Many older page-oriented CMSs have announced updated features that provide some of the capabilities associated with a headless-native CMS, the most recent generation of CMSs. These head-optional CMSs are built with functionality to generate web pages for websites, but optionally, the internal functionality that generates the display of these web pages (the “head”) can be removed or disabled if the publisher wants to utilize external user interface code instead.

Some vendors assert that their head-optional versions (also called “hybrid CMSs”) offer the same capabilities as headless-native CMSs without requiring their customers to change their CMS. In many cases, these CMSs are legacy products built on top of an architectural foundation that is ten or fifteen years old, although the branding may have changed.

Although modified page-oriented CMSs may offer headless content delivery as an optional feature or operating mode, these CMSs do not have the same architecture and capabilities as a headless-native CMS.

A black man with a tablet giving a speech in front of a group of people in an office

Basic features of head-optional CMSs

Design customization possibilities. While the CMS internally defines the layout and presentation of web pages, publishers may be able to override this setup for some or all of their content.

Partitioned mode of operation. Although the default settings rely on page-building templates, users can elect to bypass these defaults to create structured content. When organizations decide to develop customized content structures that have different characteristics than the predefined page types, they will need to manage them separately using different operational procedures. In some cases, CMS workflow support functionality may not be available for custom-structured content.

Need a separate tool to create reusable content pieces. The built-in editor of modified page-oriented CMSs does not support creating modular content. Employees who need to create reusable content pieces must use a separate editor, often developed by a third party.

Partitioned content: a mixture of predefined page types and user-defined structure. The content’s structure is often predefined, at least in part, by the CMS instead of by the publishing organization. Some structural elements may not be relevant to the publishing organization.

API delivery added. Modified CMSs often provide add-on or plug-in APIs to enable content to be delivered to touchpoints other than websites. What the API can deliver will depend on the profile of the source content. Because modified CMSs may store content in diverse ways, they may require more than one API to deliver content and not all content can be delivered to all destinations.

Predefined enhancement choices. Opportunities to enhance capabilities with external third-party tools depend on the underlying CMS architecture. When publishers want to supplement the internal capabilities of their CMS with external tools, their integration choices may be limited to a short list of vendor-provided or approved options.

Headless-native CMSs

The most recent generation of CMS—known as headless—has developed over the past decade to bring greater flexibility to content management. We’ll refer to CMSs that are purpose-built to be headless as “headless-native” CMSs to distinguish them from updated page-oriented CMSs that have incorporated some headless features, the “head-optional” CMSs discussed previously.

In contrast to page-oriented CMSs, headless-native CMSs don’t use internal templates to define the content. Once authors create the content, it’s ready for delivery without needing a template inside the CMS to first “build” a web page. Instead, headless-native CMSs rely on external code to create user interfaces for different channels and touchpoints. This arrangement simplifies how the content is developed and stored, improving its agility and availability.

A young woman using a MacBook and a man looking at the screen and drinking coffee next to her

Basic features of headless-native CMSs

Content is independent of layout. A headless-native CMS doesn’t manage the presentation layer. As a result, the internal organization of the content in the CMS, which shapes how authors create and use the content, doesn’t have to be bound up with how content is presented to customers on their devices. The content can be defined independently of a specific UI design, what’s known as “decoupling”. When that’s done, the redesign of a website or app won’t necessitate a change to the content—existing content can continue to be used in the new UI design. Decoupling content from UI design makes the content more flexible.

Publishers decide their content’s structure and organization. Instead of relying on a template supplied by the vendor, the publishing organization decides how to create and structure
their content to reflect their business priorities. They can define what parts of their content are important to manage (to reuse, personalize, update easily, or optimize). This gives them greater control over the details within their content.

Any kind of content can be modular. When using a headless-native CMS, publishers can structure their content to be flexible and platform-independent.

API delivery by default. All content created and managed in a headless-native CMS is delivered to websites, apps, and other consumer touchpoints using an API.

Content can be published anywhere. By using an API, the same content can be published to multiple places and channels.

May have limited preview of content. Some headless-native CMSs don’t provide the ability for authors to preview what the content will look like before it is published.

Open integrations. Headless-native CMSs generally support the ability to integrate other vendors’ tools and apps to support content operations. These CMSs are designed to connect to third-party applications readily, providing a wider range of enhancement options than possible with other CMS architectures.

Understanding content platform capabilities

Your content operations depend on a range of capabilities that need to work together. The CMS will provide three internal capabilities governing:

  1. The structure and organization of content
  2. The authoring environment supporting the creation of content
  3. The mode of delivery

The CMS may also provide opportunities to enhance capabilities through integration with other tools.

How these capabilities fit together defines your content platform’s overall architecture.

A young man working on a laptop in a coffee shop

Comparing content structure and organization

How content gets structured in the CMS influences the types of content and experiences your organization can create and deliver.

A basic difference in CMSs is whether they rely on templates that fix the content’s structure or whether they enable the publisher to decide the content structure themselves. This can influence the diversity of content the CMS supports.

  • Web pages: All CMSs can produce web pages, but some CMSs will only support fixed page layouts, while others support modular flexibility, which allows the composition of web pages to change as needed. 
  • Non-website channels: Only some CMSs are designed to address content for touchpoints other than websites.

The characteristics of content flexibility involve several aspects, summarized below.

Table: Differences between fixed and flexible structure

Fixed structureFlexible structure
Defined by page types or templates; the content may be organized in foldersDefined by content types that are related (linked to each other) within a content model
Decided by the vendor – modification is limited by the constraints of the CMSDecided by the publisher, who can choose how to structure their content
Channel specific (content is designed to be outputted to a specific channel)Channel independent (content can be reused in many channels)
Provides little or no ability to connect different items togetherProvides a modular structure that allows authors to compose larger items by connecting them together in a range of combinations
Can be a “black box”: authors and developers must decipher how the structure is put togetherIs transparent: both authors and developers can perceive the content’s structure and have a common understanding of it

When a CMS supports a channel-independent structure, the content can be combined in diverse ways and be reused on different websites and other channels. A page or UI-dependent structure doesn’t allow this flexibility.

Be aware that the ability to publish to more than one channel does not mean the content is truly channel independent. A CMS may let the publisher create content for more than onechannel, but not all content will necessarily be modular and able to be used flexibly. CMSs can vary in the extent that the same content can be reused in different scenarios.

Full flexibility versus selective flexibility. Some CMSs will offer selective flexibility, which limits what types of content can be reused. The content’s structure is not fully flexible when content reuse is limited to:

  • Parts of web pages
  • Content in specific UI components
  • “Content fragments”
  • “Information snippets”

By contrast, a CMS that provides a unified enterprise content model will support content that is fully modular, reusable, and ready for any channel. With an enterprise content model, publishers have the flexibility to plan what opportunities authors can target and how it is provided to readers. Content is stored in a format-neutral manner that makes it future-proof.

Capabilities comparison

On the right, you can see a table that shows a comparison of content structure and organization approaches.

Considerations: Questions to ask about a CMS’s content structure and organization approach

  • Who sets the structure or schema for the content?
  • Can any kind of content be structured the way the publisher wants? 
  • How much effort is involved to define the content’s structure in a CMS? 
  • Is the structure easy for authors to understand?
Table: Comparison of content structure and organization approach

Comparing authoring tools

How will you build your content, and what can you do with that content once it’s created? The tool that authors use influences many aspects of the content process:

  • Productivity: Does the tool help authors develop content in a strategic way? 
  • Quality: Does the authoring tool promote good content practices? 
  • Flexibility: Can authors develop a diverse range of content? Can they connect different kinds of content together?
  • Learnability: How much training is needed to use the authoring tool? 
  • Maintainability: Does everyone use the same authoring tool, or do different groups use different tools?

Kinds of authoring tools. Writers may use various kinds of authoring tools:

  1. Page editors focused on page styling, which resemble word processors
  2. Page editors that manipulate page components such as paragraph blocks
  3. Text editors that require writers to add code (such as Markdown) to their writing
  4. Structured content editors that break content into sections according to its meaning and purpose

Some authoring tools provide a preview of a web page before it is published. This can be helpful when authors will be responsible for deciding how parts of the content are ordered within a page in cases where this is not done automatically. Page editors generally offer a preview; other tools may not offer a preview.

Authoring tools are associated with the CMS in various ways. They may be a:

  • Default, built-in tool that works with how the CMS is set up
  • Alternative tool integration that replaces the built-in tool if the default tool is not adequate
  • Offline tool that is used instead of the in-built tool to develop the content

Capabilities comparison

On the right, you can see a table that shows a comparison of authoring capabilities.

Considerations: Questions to ask about a CMS’s authoring tools

  • Do all staff use the same authoring environment, or are different tools needed depending on the type of content created?
  • Is support for modular content authoring built-in to the CMS?
  • Does creating modular content require a separate add-on tool? Does the add-on tool require additional resources such as training, maintenance, or hosting?


Table: Comparison of authoring capabilities

Comparing content delivery capabilities

Why content delivery is important

APIs deliver content, connecting the content that’s stored in the CMS to various UIs where customers interact with the content. They provide the ability to search, retrieve, and deliver selected content to different destinations. An API query can specify the subject matter of the content as well as which parts of content are desired.

Most CMSs now have APIs, but not all APIs offer equivalent flexibility. An API’s delivery flexibility will determine:

  1. The delivery scope: the types of content available from an API
  2. The delivery details: the granularity of information that can be specified in a query

APIs can vary widely in what they can retrieve and deliver, as their utility can depend on the structure and organization of content stored in the CMS. APIs may provide access to various dimensions, depending on the CMS:

  • Web pages
  • Parts of web pages
  • Content for specific UI components
  • Structured data for apps
  • Modular (channel-independent) content that can be of any content type

Is all content globally available? If not all content can be delivered using an API, that will limit where the content can be delivered. It will be difficult or impossible to provide certain kinds of content in specific channels. Even if you can work around limitations, the content’s formatting might make it hard to process in some channels.

An API-first approach offers the greatest flexibility, giving the publisher control over to which user interfaces and channels to deliver the content and allowing them to refresh any details presented to users immediately. These APIs can deliver finely targeted content to customers. Publishers are not limited to preconfigured modules defined by the CMS (such as page parts, UI components, or app screens). They can decide to which frontend UI to deliver the content that would provide the best experience for customers.

Capabilities comparison

On the right, you can see a table that shows a comparison of delivery capabilities.

Considerations: Questions to ask about a CMS’s authoring tools

  • Check with developers about the ease and precision of using the available API – this influences how flexible the content will be and how agilely you can put your content to use in different channels and scenarios
  • Is the API oriented toward retrieving whole content items (less precise) or specific information in fields within content items (more precise)?
  • Assess what needs to happen for the content, once created, to be ready for delivery. What dependencies are there? Is the content useful as it is (more agile), or does it need to be filtered or transformed to become useful when delivered in the UI (less agile)?
  • Do developers see the content model structure when they create an API query? Is there a one-to-one correspondence between how the content is stored and which parts are delivered (more unified and agile), or does the query need to extract parts that are useful from within denser pieces (less agile)?


Table: Comparison of delivery capabilities

How to Compare CMS options.

Want to keep reading? Get your complimentary copy of this guide to explore:

  • The differences in CMS product categories 
  • How to ensure your setup can adapt to evolving needs
  • Best practices for making your content maintainable and future-ready
How to compare CMS options

Get the guide

You may withdraw your consent at any time and manage your data in Consent Settings. You can read our privacy notice here.