Content management systems (CMSes) have undergone many changes within a short time, featuring a bewildering set of capabilities and value propositions in addition to incurring high costs. Not only that, since modern CMSes can handle many use cases, vendors abound, each with a unique take on the core aspects of content management and delivery. In light of that, be sure to explicitly define what you aim to accomplish with a CMS.

A recommended practice in the past was to adopt a robust system that fulfills more than your needs and that you can “grow into” if and when your use cases expand. Given the time and effort involved in implementing a CMS as a long-term investment, that approach made sense at the time.

In today’s composable world, however, you should reconsider that practice because composable makes it far easier to add systems, change existing ones, and integrate them. Why tether yourself to a poor fit due to decisions made by your predecessor or a less experienced version of yourself?

Similarly, questions have arisen at mature and scaled organizations on the function of CMSes. In the past, a single system was widely assumed to be slated—and, in fact, used—for content creation, storage, aggregation, templating, and delivery to websites and channels. Given the technology advancements toward composable, vendors now specialize in individual tasks. 

A case in point: Content creation and planning might occur in tools such as Gather Content Marketing or Optimizely Content Marketing before being copied to the CMS. Delivery has now largely shifted to vendors like Netlify and Vercel while others, e.g., Sitecore and Contentstack, are partnering with those vendors to natively incorporate that functionality within their stack.

Therefore, you must consider the scope of what your CMS needs to own and for how long. If content creation, assembly, and delivery now occur outside the CMS, prioritize those features.

Website management is another topic that has undergone dramatic changes since the introduction of headless systems. Since previous generations of CMS assumed that you were building in the context of sites and pages, the product functionality matched that requirement. 

In contrast, headless CMSes specifically eschew that responsibility because of the reasoning that content should be free for use in many contexts: web, mobile, emails, kiosks. Realistically, however, most organizations are still building websites, i.e., managing page templates, layouts, and components in addition to navigation and redirects, triggering a disconnect between the requirements and the product functionality.

As a result, headless CMSes are now tasked with doing things they were not intended for. You must create new content models or extend them to manage not only content, but also navigation elements, design options (usually as drop-down menus, which are ironic for visual design), and other site-specific functions.

In other words, depending on your requirements, your system for content management might not be a fit for experience management, which is the sum of content, personalization, site structure, navigation, and redirects.

As effective as structured content and headless systems are for managing your underlying domain data and enabling reuse across channels, a disconnect often exists between those content models, which are meant to be the channel-agnostic experience you are building right now.

With a digital experience composition platform (DXCP) such as Uniform, you can shape your customer experience with placeholder content and then build, test, and iterate before locking in a content model. And, since that model can still be channel-agnostic, you can map your experience model to it. That’s an ideal setup well worth considering. Request a demo today to see what options best suit your needs.