Headless CMS FAQs

At their core, the aim of a headless CMS is to provide a way to easily create and edit your content. This content/data needs to be hosted somewhere, as does the CMS itself. Headless content management systems are either self hosted (eg. Strapi, Headless Drupal), or are provided as a SaaS offering (i.e. Contentful, Sanity, Storyblok).

Whether a self-hosted or SaaS offering is right for your business depends on your needs in terms of scalability and control. Self-hosted options will generally provide an unrivalled level of flexibility and control, though require more hands-on maintenance by an in-house team or agency partner. SaaS CMS on the other hand, offerings provide a reliable, maintenance-free experience with minimum uptime SLAs and ready-to-use APIs supplied out-the-box, requiring minimal up-front configuration.

Migration to a Headless CMS is often part of any widespread digital transformation engagement. For websites and apps running on legacy platforms, migration to headless CMS often forms a vital part of enabling the backend to interoperate effectively with a new progressive frontend. We offer comprehensive migration services to orchestrate and execute the migration of large amounts of content from legacy CMS to headless CMS without infringing on the operations of content management and authoring teams. This is accomplished through the development of custom migration workflows which are responsible for migrating content either incrementally or at once, depending on the needs of your digital transformation project.

It depends. Oftentimes, The answer is yes—as most content management systems today support Headless implementation via built in APIs. Even for content management systems that don’t offer native APIs, usually plugins exist to make this possible, or alternatively this can be developed as a custom implementation. However, whether it’s the most desirable solution is a different matter. Content management systems that aren’t built API-first could potentially require large amounts of development work in order to achieve what is required to effectively implement them as part of a headless solution to building your application. Legacy content management systems that don’t natively support REST or Graphql APIs will require custom development of a potentially large number of bespoke endpoints to consume and send data back and forth from the CMS. Additionally, such content management systems may be largely incompatible with the progressive nature of Headless and composable architecture, and are likely to be clunky and resource intensive. Legacy CMSs have typically been built with programming languages that are less desirable in the era of the progressive web, require outdated server infrastructure, and feature largely bloated code bases which have been historically prone to insecurities.

In general, when considering reimplementing your CMS to support a new, API-first approach, it’s a good time to consider whether the cms still meets the changing needs of your application.

However, some traditional content management systems have undergone widespread innovations in recent years, making them more accessible in terms of APIs, and therefore sufficiently suited to incorporation within a headless stack. Wordpress, for example, can be effectively used as a headless cms, making it possible to retain a website’s existing backend while decoupling the frontend from the cms. Other traditional content management systems, such as Drupal, have undergone larger evolutions to become API-first with a full scope of support for implementing the cms as part of a headless build, which opens further possibilities for connecting existing CMSs to a decoupled frontend without upheaving the backend and current content.

It’s worth noting, however, that modern headless CMS are often built using more progressive web technologies and are therefore generally more amenable to integration with a decoupled frontend, as this is what they were designed to do.

In summary, it’s possible to enable support for headless implementation in your existing, traditional CMS (such as Wordpress or Drupal), but alternative options should be considered as there are newer, more progressive content management systems available, which are built specifically for omnichannel, headless experiences. The optimal choice in CMS will vary significantly depending on the website/application and it’s specific objectives.