Easily restore your project to a previous version with our new Instant One-click Backup Recovery

Headless CMS

Top 6 considerations when implementing headless CMS

Here are 6 factors to consider for a successful CMS implementation strategy.

84% of companies think their existing CMS is preventing them from unlocking the full value of their data and content, according to a recent survey of 400 technology leaders on the state of content management systems (CMS).

The need to have more flexibility in how content is used, and reused, across the experience is a major reason why companies choose to move to a headless CMS. Instead of creating content that’s only meant to be presented one way on one specific webpage, a headless CMS structures content data so that it can be used in different ways across many channels.

A headless approach gives companies more choice in the data they use to create content and in how they connect the CMS with the rest of their tech stack. However, this flexibility can also bring more complexity. Teams need to go into the CMS implementation process with a good understanding of current needs, potential roadblocks, and future plans for scaling content.

Here are 6 factors to consider for a successful CMS implementation strategy.

1. Total cost of ownership

Calculating the total cost of ownership of a CMS, beyond just the licensing fee, can help you better compare your existing content system with a headless solution as well as properly scope the implementation process.

Costs to account for include:

  • Implementation cost: This includes the time and resources needed for creating content structure, developing custom features, auditing and migrating content, data integration, and user training. As well the cost of working with an external CMS implementation partner, if needed.

  • Maintenance cost: What parts of infrastructure, performance testing, monitoring, cloud hosting, site backups, and security updates are handled in-house and what is taken care of by the vendor as part of a software-as-a-service license? Do you need to factor in downtime costs for big version changes, or are updates rolling and backwards compatible?

  • Operational cost: 74% of technology leaders say that improving the ability to expose data and content would significantly reduce operational costs. How can you set up the new CMS to eliminate content bottlenecks? What would the productivity savings be for development and marketing teams with these changes?

  • Scaling cost: Can the platform easily support increase in traffic and API calls, or will it take substantial development to ensure performance? What effort is needed to add new services, data sources, and channels? Does the CMS vendor have a clear pricing plan to show how costs change as your business grows?

2. Frontend delivery

The core principle of headless content is that it can be delivered to any frontend (the “head”). An early headless CMS implementation step is deciding what frontend framework(s) to use, and understanding the APIs you’ll be using to connect content to frontend channels and other backend applications

Frontend frameworks offer logic and a library of code for efficient development of user interfaces (UI). The choice of framework depends on both your use case and on what technologies your team is already familiar with. Popular frontend frameworks include React, Angular, and Vue.js.

Most headless CMS solutions deliver content with either REST APIs or GraphQL APIs. A more technical comparison of these APIs can be found here, but in general:

  • REST API: When information is requested, a REST API will send a full set of data back in a neutral HTTP format and the receiving application then chooses which pieces of data to use and how to use them. This “dumb pipes, smart endpoints” approach was critical to the rise of headless and microservice architectures.

  • GraphQL API: GraphQL is a query language that was developed by Facebook engineers when they needed a more efficient way to fetch data for the News Feed section in the mobile app. GraphQL gives data a structure and hierarchy that makes it possible to request just the information needed instead of over-fetching a full set of data.

Both REST and GraphQL have advantages in different use cases. A GraphQL-native CMS, like Hygraph, is particularly useful for companies that use multiple data types and sources to power their content.

When choosing your CMS it’s important that the APIs not only fit your use case but are well documented and easy-to-use, as 92% of technology leaders find it challenging to manage the number of different APIs, standards, and interfaces needed for CMS development.

3. Team capacity and capability

Figure out what additional resources you need to get the system up and running. Does the vendor provide training, implementation guides, and direct support? Does your team have the time and skillset to do everything in house, or will you be working with a CMS implementation partner?

A good implementation plan also includes steps to make sure both developers and content teams are capable of managing the experience once it’s in place. As the most frequently reported challenge that technology leaders have with their CMS is that changes can only be made by a small number of people with the right skills.

This includes steps like involving both sides in the content modeling process, to making sure core features and workflows are in place, to providing clear onboarding and user training.

4. Content structure

To be able to deliver content to any frontend channel, a headless CMS needs to structure data so that it can be easily fetched by APIs.

In Hygraph, this is done by breaking up content into reusable blocks of information, or “content models”. For example, you could create a content model for hero banners, author bios, blog entries, product attributes, product categories, SEO information, or site navigation. Content structure includes a defined set of models, the data they require, and how they relate to one another.

Especially for teams coming from a page-based CMS, headless content modeling can take a whole new way of thinking about content production. It’s important to include developers, content editors, designers, and business stakeholders in this process to see the full picture of technical and marketing considerations and create a practical, scalable content structure.

For a more in-depth look at headless content modeling, check out the essential guide to content modeling in Hygraph.

5. Content migration

Once your content models are defined, you then need to migrate existing content into the new structure. With Hygraph, this is generally done in two ways:

  • GraphQL mutations: Mutations are used to migrate assets and content data into Hygraph in a way that allows them to be accessed and updated using the GraphQL API.

  • Content Federation: Hygraph uses a novel process called content federation to fetch data from multiple remote sources in a single API call. It allows data to continue to live in the original source, so there’s no duplication, while giving users one place to access and manage all information. Some companies use content federation to connect their legacy CMS with Hygraph, and then gradually migrate data as they step off the old CMS.

For more information, take a look at the developer guide on migrating to Hygraph.

6. Data integration

88% of technology leaders find that managing integrations and middleware is an innovation bottleneck. As tech stacks grow and companies shift towards more composable architectures, data orchestration will increasingly be what makes or breaks digital experience.

Hygraph’s Content Federation is a novel way of connecting data from remote sources that takes advantage of GraphQL’s ability to fetch only the information needed. It removes the burden of having to create custom middleware for content data, allowing teams to efficiently serve data from multiple sources with a single API call. Data continues to live in the original source, with Hygraph acting as an API gateway that grabs the most up-to-date information whenever it’s requested by customer frontends, internal users, or automated systems.

Future-proof content with a headless CMS

80% of technology leaders are concerned about how future-proof their existing CMS is.

A major driver to choose a headless approach is the ability to adapt structured content to new channels and applications without having to rewire the systems, and a good implementation plan helps ensure the content processes you set up today will be able to adapt to tomorrow’s needs.

Of course, the technology selection will also have a big impact on how future-proof your content is. Such as choosing a CMS that supports a composable architecture, where you’re not locked into rigid process or feature sets of a vendor, but can mix-and-match services to create your own tech stack. Or a software-as-a-service offering that takes the responsibility of maintenance and updates off your team’s plate.

To help companies evaluate and compare CMS options, we’ve put together a list of RFP questions for headless content platforms.

As always, please don’t hesitate to get in touch with any questions about the Hygraph platform, our CMS implementation services, and how we can help solve your specific content challenges.