The migration costs and the status-quo bias towards staying with monolithic or custom-built CMSs are delaying the migration of companies to headless CMSs, creating a barrier to digital transformation.
Traditional monolithic CMSs were the go-to solution for managing website content in bulk, offering an all-in-one approach with integrated frontend and backend functionalities. From the early 2000s to the mid-2010s, custom-built CMSs were the only way to meet diverse digital experiences and performance goals, especially for content-heavy businesses in media and publishing. Today, this is no longer the case.
Headless CMSs can accommodate any digital project's complex content and workflow needs and power with data, even the most demanding frontend experiences. They are a cost-effective and balanced solution that allows customizability at a reasonable rate. In short, a headless CMS is the stepping stone to making more efficient use of your content.
In this article, we will examine what the evolution of content management means for your organization, why following the headless, pro-API approach eads to a better digital experience, and how you, as an engineering lead, can convince your organization that headless is the right approach.
#Why content management had to evolve
The evolution of CMS mirrors the progression of the digital experience. Initially, digital experience entailed only browsing webpages, and monolithic CMSs were enough.
However, as the importance of web channels for media distribution grew, developers within larger enterprises recognized the limitations of monolithic solutions in handling complex, structured content or providing unique frontend experiences.
This led to the rise of custom, in-house CMS solutions. Performance and extensive customization were now guaranteed but at massive engineering costs and hard-to-find know-how to design, build, and maintain these systems.
Is there a way for more businesses to take advantage of the benefits of a custom content system optimized for two or more channels?
Since 2007, the surge in smart devices has ushered in a new era of content consumption across diverse channels. This shift put significant pressure on both monolithic CMS technology and content teams.
Organizations struggle, and many continue to struggle, to deliver precisely timed, consistent, and relevant content via the right channel. On a completely different front, maturing JavaScript frameworks and the arrival of Static Site Generators became appealing to developers eager to build performant websites.
The need for a multi-channel content strategy and a modern, performant tech stack made the limitations of a traditional CMS far more evident. According to a recent survey, 8 in 10 tech leaders, even today, think their current CMS is holding them back with inefficient developer or editorial experiences.
The solution was found in decoupling the presentation and the content layer with the headless CMS.
With the rise of digital product models, content is increasingly becoming the actual asset that is sold to customers instead of just the marketing offering around a product. With this, we see an increased demand of handling structured content at scale similar to a database, but with CMS functionality on top.
Editor's Note
To learn more about the different types of CMS, we recommend reading other Hygraph knowledge pieces
#Reasons to modernize your CMS
If you manage content for your organization, you will likely have some objectives and key results to report to the broader team. If your CMS is a weak link preventing you from reaching your goals, you should consider modernizing it.
However, many organizations hesitate to transform due to the learning curve, implementation effort, and potential investment increase. To achieve transformation, it is important to recognize the opportunities you might miss due to outdated technology and unoptimized operations.
Here are some common considerations for modernizing your CMS. The list is divided into 2 sections: technology and content, reflecting unique team needs and objectives.
Criteria for technology
Developer velocity: Accumulated tech debt can slow release cycles and prevent your organization from having a continuous release schedule.
Talent acquisition: Legacy systems are hard to understand and make developers less productive. If you work with old technologies like .net and PHP, chances are high that you can’t hire and retain the best talent. Rather than hiring people with additional skills for CMS reasons, if everything you need to work with the CMS can be easily found in any tech stack, it's much easier to handle things in-house.
App performance: Performance is a key indicator of your project's success. It's also closely connected to your business since you lose revenue when your performance is poor. A CMS's failure can be detected by business metrics such as lost revenues, cart abandonment, bounce rates, etc., which are influenced by poor performance indicators such as slow page load speed and low core web vitals.
State-of-the-art technology: The technology landscape is ever-evolving. Naturally, some of the latest technologies work better than outdated ones. The advantage of a headless CMS is that you can choose any technology you like and easily switch the frontend without changing your CMS. The Jamstack technologies are easily compatible, and the latest mobile application technologies like Flutter can easily be used with any headless CMS.
Technology strategy: A tech leader should choose IT vendors that can adapt quickly to an unknown future. A headless architecture enables microservices to be built in a functionally decomposed way that makes it easy to change parts. You won’t be able to do it if you buy an all-in-one solution for 10 years. On the other hand, a custom CMS might be good for smaller projects, but once you scale it, you have to choose between the needs of CMS users and clients to focus on. It’s not future-proof, and you are stuck maintaining a code base.
Security: Unlike a traditional CMS, a headless CMS decouples the backend content repository layer from the frontend presentation layer. This separation allows for greater security because the content management layer is isolated and can be protected independently.
Criteria for content
Content governance: Can your CMS help you centralize disconnected content and reduce content silos? Content silos are pieces of content isolated across different CMS and storage databases. Your content governance becomes increasingly challenging when you have a big content team or operate in multiple markets, and production can be slowed down due to the approval process. Your CMS should enable you to manage stakeholders and reuse content efficiently, not the opposite.
Delivery to multiple channels: In an era when people own an average of 3.6 connected devices per person, the desktop no longer dominates website presence. Content needs to be delivered swiftly to multiple channels like mobile apps. You shouldn't do repetitive tasks to deliver content to different channels.
Create richer experiences: After visiting your website, your audience should be able to remember you as a brand. It will be tough if you are limited to fixed page templates and dependent on the development team whenever you need to create a new page type or a specific piece of content.
Personalization: In the upcoming cookieless world, brands strive to keep customers on their websites by tailoring content to individual preferences and needs. Personalized experiences enhance user engagement and drive conversion rates. For example, the website only pushes content based on each user’s preference. The CMS should allow content creators to adjust and tailor content based on user data dynamically so each visitor receives relevant content tailored to their needs and interests.
Increase content velocity: Content production speed is one of the most important competitive factors for many brands. If you're struggling to update content across several parts of your website or having trouble creating content within your CMS, you might lose business to your competition if you don't look for a faster solution.
Localization: A CMS incapable of efficiently localizing content or that requires replicating the entire page structure to localize content may prevent you from launching quickly in new markets.
Focus on the content: Web editors can be distracted from producing content when CMSs demand technical skills like HTML, Javascript, and CSS. Conversely, a headless CMS allows writers to focus solely on content and building experiences.
Design and brand consolidation: You can leverage your modern CMS to build a design system. Consolidating the brand experience can be difficult if you have a lot of CMSs. Developers must construct components differently to represent the same thing, so you cannot reuse the same design throughout all your projects. Amazon's user experience was different in the early days, for example, as they brought in new services, confusing users.
A headless CMS separates the frontend and backend of a CMS. It is the natural evolution of digital transformation. Leave the CMS without a head and let the content be delivered to any modern stack via APIs (e.g., GraphQL APIs) provides access to a powerful backend. This approach lays the foundation for organizations to meet their technical and content requirements swiftly:
You aren't restricted to publishing content to a single website or mobile app. A headless CMS allows you to develop with any technology for any platform, making your product scalable when your users need you to be.
A headless architecture minimizes knock-on effects and ensures that each part of the architecture does one job extremely well. Therefore saving costs and gives you more flexibility with your stack.
With headless CMS, organizations can scale the backend infrastructure independently from the frontend applications. This means they can allocate resources based on demand, ensuring optimal performance and reliability during traffic spikes.
With a headless CMS, you can model content modularly so that it is treated as data and can be called upon in various circumstances. In Hygraph, we call this structured content. Your content can be organized and designed to be reusable and flexible for various projects.
A headless CMS allows your content to be modified immediately and as needed by your content creators. Minimize the impact of redesigns, product changes, and migrations with a decoupled content solution. Additionally, you don't need to worry that a headless CMS won't be able to deliver content to another digital channel that emerges five years from now.
There is no need to teach a prehistoric web template language just to manage your content. Instead, your team can work with any modern language stack they choose.
#Why not build a custom CMS?
If it’s obvious that the market landscape is shifting away from monolithic CMSs, why not build a custom CMS?
For a while, it made sense for companies leading the way in digital to create homebrew solutions to fit unique industry needs or business strategies. But as the digital experience has grown, even companies with excellent homebrew solutions for the web five years ago are finding that their customer needs and digital ambitions exceed what they are able to handle in-house.
The customizability of an in-house CMS comes with the price of maintaining all the moving pieces to keep the system healthy. It’s also less scalable as it’s usually built by a small group of people, so they are the only ones who can access and make changes to the system. As a result, it’s hard to manage as your project scales, and the small group of developers who built the solution will be stuck maintaining the code base.
A headless CMS not only uses APIs to deliver content to any frontend but also builds all the platform functionality to be API-enabled from the ground up. This gives businesses a vast amount of flexibility in how they leverage and extend these services to create their own unique experience.
#Monolith vs. custom vs. headless: a side-by-side comparison
Let’s look at how monolithic vs. customs vs. headless CMS compares in terms of costs, flexibility, security, and more.
SaaS-Composing your solution is like buying paid insurance for customer satisfaction, performance, and security.
The composable SaaS model can be compared to buying insurance: insurance that your product will be secure, its components will have a high NPS and Performance rating, and that its components will already be battle-tested by thousands of other customers. You won’t be the experimental guinea pig alpha customer of the product. And if you build it, you are the only customer.
Implementation costs and risks
Monolith
High licensing costs. Expertise in the monolith and specific language (e.g., AEM—the learning curve is huge) is required.
Custom
It requires highly skilled and experienced experts. There is uncertainty about functionality, scope, unknowns, and total ownership costs. It requires a massive upfront investment—do you even have the resources?
Headless
Generalists are needed for setting up the frontend. Your team is good to go after onboarding.
Homebrew CMS projects have gigantic hidden costs for HR, PM, design, and docs.
Whereas licensing costs for services like hosting the database and the application are known, teams often neglect the complexity of projects that require manpower for research, coordination, project management, recruiting, design, implementation, ongoing maintenance, vulnerability management, creation, and maintenance of documentation. If you start a new, even moderately complex, custom CMS project, you may need to hire an additional developer. At current market rates (2023) for recruiters or internal HR managers, with the onboarding costs in mind and having in mind the onboarding costs until full productivity, a new hire can easily cost 15-40k USD!
More importantly, your VP of Product has given you some timelines. A custom built-CMS project will take much longer and will require diverting resources from multiple people who are in completely different development cycles.
Customization degree
Monolith
Lower flexibility to change.
Custom
You can custom-build your whole backend - editorial features, engineering, hosting, apps, etc.
Headless
Provides flexibility to set up workflows, pick hosting locations, and use app frameworks if available with vendor.
What can be customized?
How much customization do you need?
A manufacturing leader was moving away from Sitecore to a headless CMS. The 100+ item RFI Questionnaire had a detailed requirement about a particularly complex custom workflow. The content management team had strong feelings about mapping their Sitecore workflow to the new CMS. The business requirement could not be matched with either of the new alternatives.
Give the headless CMS's out-of-the-box workflow a chance—at least for the trial.” The team not only didn’t complain, but they were excited about how much easier the new workflow was. It’s most likely going to be fine with everybody. It is so not true that content teams can’t adapt. They can learn and unlearn.” Requirements are often mixed with current (inefficient) experiences.
I do this now, so the new system has to do it. Ultimately, so many customizations come from wrong requirements not groomed and clarified properly.
Frontend flexibility
Monolith
Either only templates or frontend frameworks with limited availability of engineers. Either not multi-channel or has limited API capabilities.
Custom
Unique frontends, can deliver to any channel via a custom API.
Headless
Unique frontends, can deliver to any channel via a custom API.
Are you aware of all the edge cases that building a new custom CMS will involve?
Danone decided to launch a store locator picker experience on their website. Initially, an engineering team was tasked to build it all using only partially external APIs like the GoogleMaps API. Only after a major pushback did the team realize that the scalability of their application would be a major issue and that they were not even aware of all edge cases related to the applications’ business logic. It was decided to go for a commercial SaaS vendor.
What user interactions make sense? Who will be in charge of research and design? What vulnerabilities may emerge if you build the application? Do you intend to have your application security audited? What are your application’s implications for SEO? How do you guarantee scalability? How much time will you dedicate to building and maintaining the solution? How much time are you ready to dedicate if the solution goes down?
Web vitals/application performance
Vendor lock-in
Monolith
High migration costs, organizations often opt for stepwise moves; content structures need to be redesigned completely frontend front-rebuilt.
Custom
Huge dependency on the team to design, architect, develop, and document the system.
Headless
API-first systems are more easily replaceable, generalist developers sufficient (JS and API knowledge).
Expert knowledge of your stack
Monolith
A pool of engineers who have worked with the specific monolithic CMS solution and the programming languages required for its operation.
Custom
New engineers have to undergo a rigorous and prolonged onboarding on the system.
Headless
Knowledge of the CMS system and its API is usually not required unless a proprietary API format.
Content complexity
Monolith
Mostly content model templates.
Custom
The creator of the CMS has full theoretic flexibility to use any database and create any custom data structures.
Headless
Very high flexibility to create custom data structures. Some CMSs support multi-directional references between models.
If you build a custom CMS, only your team will share feedback about improvements and bugs. You will always be the one to uncover issues and won’t rely on a large community of previous users who already made the product better.
CMS user community
Monolith
Thousands of users report issues. A widespread monolithic CMS has existed since early 2000-2005. Technical documentation is reliable, complete, and constantly updated.
Custom
Only 1 company uses the system and reports issues. Documentation is sometimes missing or not updated regularly.
Headless
Thousands of users reporting issues. First headless CMSs around since 2014. Technical documentation is reliable, complete, and constantly updated.
Maintenance costs
Monolith
Competition between monoliths and new entrants keeps prices and quality in check.
Custom
The entire codebase and docs must be maintained, bugs fixed, and improvements created from scratch.
Headless
Competition between new and old vendors - improving the products, fixing bugs, and securing systems. While industry leaders often hike prices for existing customers, price pressure for new contracts is high. Maintenance costs for the frontend.
Security
Monolith
Usually audited and certified, but higher risk due to aggregation of data in the hands of one vendor.
Custom
Multiple security experts must be involved to ensure a solution is truly secure. Little incentive to get independently audited.
Headless
Diversification of data hosting responsibilities (e.g., eCommerce vs CMS data) reduces the risk of all data being exposed if an attack is successful.
Security of composed solutions is the highest among CMS approaches
The claim that a composable solution is less secure than a monolithic solution or homebrew is rather weak. Nowadays, all of your vendors will be SOC2 compliant or ISO27001 certified. The growing security certification and audit industry is creating strong competition among even the smallest vendors to take data privacy and security seriously. Do you intend to audit your implementation? Do you have multiple in-house experts taking care of security?
By separating responsibilities among several software components, you are diversifying. Different vendors have different permission and access levels to different segments of your data, unlike a single monolithic vendor or your custom solution.
Are all your eggs in one basket or multiple baskets?
#How to advocate for CMS transformation in your organization
Sharing a 90s playlist with your peers can get you an emoji wave. If your content management architecture reminds your team of the decade when the first CMSs were released, you better get your boss’ approval to change the tune.
While ancient systems like RAINMAN (developed by AOL around 1992) are probably not in use, many companies are still stuck with their younger contemporaries. Legacy platforms like Joomla, Drupal, and WordPress and their monolith enterprise cousins:
- Do not offer the content modeling flexibility modern web-based projects need;
- Do not allow an affordable connection of content with modern frontend frameworks and
- Can not efficiently deliver content to smartphones, IoT devices, and voice assistants.
Now you know a headless CMS enables you to decouple frontend and backend, get rid of content silos, build your content model as you like it, and focus on APIs that deliver content to any channel. All this dramatically increases your team’s productivity, decreases your dependence on obsolete technology, and improves your time-to-market for new features. How do you convince the decision maker of your team?
You've got 6 steps to convince your boss to go headless, inspired by 90s songs.
1. “All that She Wants” – shape your suggestion in the form of your boss’ needs
You have your OKRs and headaches, and so does your boss. So, think of how going headless can help solve their problems. Do they need to tighten the budget belt or expand with new digital channels and into new markets?
Migrating to a headless CMS leads to mid- and long-term cost-savings and relieves IT teams of legacy CMS chores. If opening new digital channels is not the focus, emphasize burden relief. If your boss has ambitious plans, focus on the benefits of headless for enabling IT teams to ship features much faster. Deal a final blow by pitching an optimal API solution like GraphQL – an API that comes in any shape you need and offers you massive performance and productivity gains.
2. “Everybody Hurts” – point out the pain
Does your department have trouble hiring frontend developers or developers with legacy CMS skills? Does shipping new features take ages? Do you need to maintain several CMSs? Or do you need to deliver content to new channels?
Quantifying the pain behind these questions will solidify your case. Finding new tech hires with legacy-CMS-specific skills often sets your project back by at least several months. Maintaining multiple CMSs to power multiple digital properties exponentially increases the time costs of both your developers and business users. Setting up a new project with a traditional CMS will often take 4-8 times longer than with a headless CMS like Hygraph.
3. “Somebody Dance with Me” - get others on board
You don’t need an orchestra, but a trio will help you get your voice heard. Who else in your company can benefit from a headless solution? Is the marketing team constantly bugging the developers for help with content? Is a project manager planning a new product or feature and needs a flexible, easy-to-setup CMS?
Aside from the pains experienced by the IT department, here is a list of potential pain points from different stakeholders of a company with the CMS.
Marketing department: Marketers are frustrated with the limitations of the current CMS in delivering personalized content and efficiently managing campaigns across multiple channels. They seek a solution allowing advanced content personalization and agile campaign management without being hindered by backend constraints.
Content editors: The current CMS challenges editors in structuring content, managing workflows, and ensuring version control, leading to inefficient content production and distribution. To enhance content management processes and productivity, editors seek a solution with structured content creation, streamlined workflows, and robust version control.
UX/UI Designers: Due to constraints imposed by the CMS, designers encounter limitations in designing rich user experiences and ensuring responsiveness across different devices. They seek a solution that offers design flexibility, responsive design support, and control over content presentation to optimize user interactions and interface design seamlessly.
Revenue Generation Team: Your commercial team grapples with the CMS's inability to deliver personalized shopping experiences and seamlessly integrate with eCommerce platforms, leading to missed revenue opportunities and suboptimal conversion rates. They seek a solution that enables personalized experiences, seamless integration, and optimized conversion funnels to generate revenue and improve user satisfaction.
Project Managers: Due to limitations in the current CMS, project managers encounter challenges in managing project workflows, facilitating collaboration, and ensuring timely project delivery. To achieve successful outcomes efficiently, they seek a solution that streamlines project workflows, enhances collaboration, and accelerates project delivery.
Product Managers: Product managers face difficulties in iterating on product development, integrating with existing tools, and delivering enhanced product experiences to users within the constraints of the current CMS. They seek a solution that enables faster iterations, seamless integration, and improved product experiences to effectively drive product success and innovation.
4. “Love Don’t Cost a Thing” - run a low-risk proof of concept project
Nothing is more convincing than your own experience. Get some positive results by running a low-risk, low-investment proof of concept project. Monthly costs as low as $199 are enough to get you started. Make sure to define several success criteria in advance. Great candidates for such criteria include ease-of-build, setup time, developer satisfaction, system flexibility, and business user onboarding time.
5. “I Don’t Want to Miss a Thing” – create a sense of urgency
Creating a sense of urgency and a fear of missing out may be the final nudge your manager needs. An API-driven approach is no longer only for innovators and early adopters. Mention some big names already using a headless CMS (e.g., Samsung, Dr Oetker, Spotify). Mention a competitor who has upgraded to headless and share case studies with them. Don’t let your company miss more customer touchpoints—in addition to the ones in a browser.
6. “You Get What You Give” – work hard to make the trial work
Making the proof of concept a success is up to you. If the trial works and the change comes in place, you will be the hero who saved your company's stress and money and opened the door to new product development opportunities. How to make it a success?
Start with a realistic goal and deadline. Create a list with your success criteria and milestones. Get help from the CMS company - customer success managers are here to make your trial work. Let them consult you and provide you with onboarding materials. Provide instructional content to all users of your CMS – content creators and developers.
Download eBook: Future of Content
Insights from 400 tech leaders on CMS pain points and trends.
Download eBookBlog Authors