Migrating to a Headless CMS

Today there is a seemingly endless variety of ways for users to consume content online. Not only is there every conceivable size of screen across wearable, mobile and desktop devices, but also smart TVs, voice-controlled home assistants, Augmented and Virtual Reality (AR/VR) applications, out-of-home experiences, and more. And this trend is only set to continue, with estimates from MarTech Advisor suggesting that each person will own 15 connected devices by 2030.

As a result, organisations are being forced to review how their digital platforms are set up to cater to the growing number of devices capable of receiving content.

For many, the answer lies in a ‘Headless Content Management System (CMS)’ approach, which separates content from its front-end display to provide increased flexibility of delivery. Indeed, according to Econsultancy in 2018 16% of marketers were using a headless platform for their content marketing, with a further 21% planning to adopt the approach within 12 months.

In this post we’ll explore whether a headless CMS setup represents the future of content management, covering some of the key features and benefits of the approach as well as how it compares to other popular solutions, to help you decide if it’s the most appropriate option for you and identify the next steps in your journey if so.

What is a Headless CMS?

Summary

• Front-end decoupled from back-end
• Connected via APIs
• Enables delivery to multiple channels in multiple formats
• Ideal for content-heavy organisations
• Can introduce unnecessary complexity for simple sites

“A headless content management system, or headless CMS, is a back-end only Content Management System (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device.” Source

Firstly, it’s important to understand how a headless CMS differs from a traditional content management system, which typically controls both the front- and back-end elements of a website. In contrast, a headless CMS only covers the back-end components, with front-end elements decoupled and connected via a robust API layer.

Where a traditional CMS will control how content is stored, managed and displayed to the user then (for example through templates, site structure and design elements), in a headless setup the CMS only stores and manages content. It is then delivered to a separate front-end application (or applications), which is what the user ultimately consumes.

This greatly increases the options available to display content, including introducing the possibility of third-party integrations, as well as custom-developed platforms.

Alternatives to a Headless approach

The headless approach has grown in popularity over the past few years, and does offer many benefits which we’ll cover a bit later in this post. However, it’s worth understanding some of the other common content management solutions out there, to help you make an informed decision about the most suitable option for you.

Traditional off-the-shelf CMS

Summary

• Controls both front- and back-end
• Provides tools to display content
• All-in-one solution can reduce complexity for simple sites
• Can limit front-end delivery options

As mentioned above, off-the-shelf content management systems have traditionally covered the full content experience. While specific features and functionality of course differ from product to product, generally these systems offer a range of built-in tools to control how content is displayed – for example, supporting responsive frameworks to optimise the user experience across devices.

As a result, going down the traditional CMS route is still a great choice if:

• You’re looking for a website to target mobile and desktop devices, and don’t require any particularly advanced content delivery processes
• You’re after an all-in-one solution to reduce complexity and, subsequently, time spent maintaining your system
• You want to minimise initial development cost, or have a business need to get to market quickly
• Your content team need to be able to easily control how content is displayed in the front-end (without requiring specific technical skills)

If you do choose this option (also known as a ‘monolithic’ approach) though, it’s important to be aware that:

• Any additional front-end channels, such as native mobile applications, will need to be managed separately
• You’ll also need to set up integrations for any external content sources you want to bring in, for example third-party data feeds or user-generated content

Bespoke solution

Summary

• Full control over content management and delivery
• Integrate front-end elements to target specific channels/devices
• Good for highly complex or specific requirements
• Will increase upfront development costs and timescales

When dealing with a more complex digital platform – for example, one that requires specific back- or front-end functionality, or a number of custom integrations – developing a bespoke solution has traditionally been the most appropriate option.

Key benefits of this approach include:

• Having complete ownership over your solution, without requiring the licensing or support fees that can come with off-the-shelf products
• Being able to implement features that meet your specific requirements, such as custom workflows, roles and permissions
• Targeting the full range of devices you need to serve – and only these devices, to avoid wasted development
• Controlling your short- and long-term roadmap, to allow more security around future planning

Bespoke development does, however, come with its own set of considerations:

• While you may avoid the licence costs associated with an off-the-shelf solution, the initial development costs are likely to be higher, along with longer project lead times
• You’ll also likely need to set up custom support arrangements to safeguard uptime, security and performance, compared to the packages often offered as standard by CMS vendors and partners

What are the benefits of a Headless CMS?

In many ways, a headless approach represents a balance between off-the-shelf and bespoke development options; taking the back-end elements from an off-the-shelf system and connecting these to front-end display elements via custom APIs.

As such, it can deliver a number of benefits including:

• Reducing initial development costs when compared to bespoke development, and speeding up time-to-market
• Providing a foundational platform with a range of out-of-the-box functionality, and so allowing development effort to be focused on custom features only
• Giving complete flexibility in terms of front- and back-end integrations, for content to be delivered to any channel in any format

Who uses headless CMS?

The level of flexibility offered by a headless approach makes it ideal for organisations that need to get a platform or product to market quickly but whose needs aren’t being served by existing systems on offer, or who are exploring new front-end channels and don’t want to build a new solution from scratch. It’s also a great choice for those with content-heavy offerings, such as publishers or ecommerce platforms, who need to deliver this content in a number of different formats across native apps, syndicated feeds, and even areas such as in-store signage.

However, while a headless approach does combine some of the best aspects of traditional approaches, it shouldn’t be seen as a magic bullet. For example, you’re still tied to the back-end elements of whatever platform you select, so may need to tailor your workflows and other content management processes. An alternative approach is to create your own administrative interface, which itself brings challenges around duplication of effort and limited short-term return. Compared to a traditional CMS too, a headless approach introduces an additional layer of complexity, and potentially another skillset for your development team to master.

As such, if the site you’re managing isn’t particularly complex an off-the-shelf solution might be best for you, while if you need a system where both the front- and back-end elements are tailored to your needs you may well want to proceed with a fully-bespoke option.

Planning your Headless solution

Summary

• Skillset
• Infrastructure
• Non-functional requirements
• Migration

If you do decide that a headless CMS is the most appropriate approach to meet your needs, then there a number of factors you’ll need to consider to ensure your solution delivers maximum value:

Skillset

It’s likely that moving to a headless CMS will require new and different skills, which you’ll need to make sure are covered by the team undertaking your development. If your platform is going to be hosted internally, you may need to hire more developers with front-end or API skills, or invest in upskilling your current team. If you’re outsourcing development, you’ll want to conduct a thorough supplier selection process to validate that your chosen supplier/s can effectively manage the development and architecture of a headless CMS.

Infrastructure

Speaking of architecture, it’s vital to plan for the supporting infrastructure that’s needed to effectively run your headless platform. Does your hosting solution need to be reviewed and revised, for example, to accommodate a more disparate selection of applications? Think too about how these will interact with any analytics, transactional and marketing solutions you have in place, as this may require further integrations, or new systems that are better suited to a headless model.

Non-functional requirements

Non-functional requirements, also known as Quality Attribute Requirements (QARs), are the characteristics your software should display, separate from any specific features. Common quality attributes include security, stability, scalability, maintainability, usability (any ‘ility’ really!) as well as things like performance under heavy load, or compliance with sector-specific or other regulations.

It’s important to define which non-functional requirements are a priority for your platform and for your wider organisation, as this will help you understand where you’re not being served by your current platform and validate that you’re making the switch for the right reasons. You should also use these requirements to inform metrics that you can gather data against to measure the success of your new solution, which you should be capturing at both a quality and an outcomes level.

Migration

If you’re planning to migrate an existing platform, it’s crucial that your migration is planned in such a way as to minimise disruption to your service. This may involve building your headless solution separately and switching everything over at once, although a phased approach can deliver results more quickly and cost-efficiently.

For example, you might want to build and/or swap out the highest-priority elements of your system first to maximise value, and enable you to adjust your future roadmap in response to early analytics and feedback. A phased approach can also be used to incrementally move across to a fully-bespoke solution, if you find you need more control or want to ultimately eliminate licencing fees.

Summary

If you’re looking for a flexible way to deliver your content, while retaining the usability and support offered by a trusted CMS, it’s definitely worth considering a headless approach to manage and deliver your content in future (although there’s still a place for off-the-shelf and bespoke options too).

Headless solutions can also be valuable if you want to get a complex platform launched and generating returns quickly – but it does still need careful planning to make sure you get what you need from your platform. Any work should therefore be informed by an in-depth discovery phase, to capture the key stakeholder requirements, user insight and success metrics that will guide development. It’s also important to regularly review the progress of your project, to ensure it remains aligned with your business goals and can be adjusted as needed.