How to choose a tech stack when migrating to a headless CMS

Choosing the stack is the first step in a replatforming project toward a composable architecture with a headless CMS.

It is possible to freely choose the building blocks, selecting those with which we are most familiar and which best meet the project requirements.

Below, you will find insights for evaluating each part of the stack based on direct and and feedback shared with us by our long-term customers, partner agencies, and ambassadors.

Framework

This part is critical because it strongly influences the DX and productivity of the developers engaged in the project.

New frameworks emerge constantly, but the most established ones among our users are Next.js, Astro, Nuxt, Vue, React, Svelte, and Remix.

It is important to check the availability of official SDKs and tutorials from your headless CMS. If your product does not support your technology well, you will also need to calculate the initial cost of independently developing a small POC to integrate your framework with the CMS.

Storyblok provides an SDK ecosystem for modern and well-proven frontend frameworks , with a very similar DX across technologies, allowing users to test different technologies easily.

Hosting

There are hosting platforms designed specifically for headless projects that integrate seamlessly with the rest of the stack. The best-known players in this area are Vercel and Netlify.

These platforms allow you to quickly create the environments you need for your project . Moreover, they allow you to generate deployments for each branch of a repository to share the work in progress with stakeholders in order to have it tested or reviewed.

Of the many features available in each of these services, you should check specifically:

• Availability of an integration for the framework used.
• Cost of traffic. This matters even more if the project assets will be served by the hosting platform’s CDN because the traffic volume might be very high.
• The build minutes included. If the project is small and the build time is fast this will not be a problem, but for larger projects or in the case of very frequent deployments this parameter becomes very relevant.
• Whatever other features are needed for the project (e.g., password-protected URLs, lighthouse score for each deployment, etc.).

Backend functions

In a headless stack, it is natural to separate backend functionality into individual specialized services between serverless and third-party functions.

Every headless CMS has an ecosystem of integrations that can help you compose your own system without having to do everything from scratch.

The benefits derived from such an architecture are:

• Ability to choose the best tool for each feature. Since we are not constrained by the technology of a single backend, we can choose the tool that best meets our needs. It does not matter what language the services are developed with because they will communicate with each other through APIs.
• Problem isolation: in the event of downtime or errors by one of the services, the rest of the stack will be able to continue functioning.
• Low tech debt: upgrading individual system components will be easier than having to do so with a single monolith.

Customization and automation

Backend operations that cannot be done with third-party services can be accomplished through custom serverless functions.

Some common examples might be handling form submissions, votes for articles, and running automatic flows that can be called from either the frontend or the backend via webhooks. For a more concrete example, read our article on cross-posting to social media using a headless CMS .

The hosting platforms mentioned earlier provide tools for creating serverless functions very quickly, with the ability to publish them in a single deployment along with the rest of your project.

These solutions have limitations that suit most cases, but in case there is a need for more control of the endpoint setup you can use services such as AWS Lambda.

Search functionality

Content search is a popular feature, either for finding text within an entire site or for filtering a list of pages of a specific type, such as products or tutorials.

Some headless CMSs have APIs that provide functionality suitable for serving simple search interfaces. This is the quickest and most cost-effective solution, requiring at most the creation of a proxy to forward requests to the API while not exposing the API authentication credentials client-side.

When the search requires filters or result sorting logic that are not available with the CMS API, third-party services such as Algolia can be used.

An important aspect to consider is the integration between the CMS and the search platform, which must receive all searchable site content whenever it is created or updated. This can be achieved through webhooks or with an integration between the two platforms provided directly by them.

Storyblok provides integrations with several search services , which allows you to free yourself from the burden of developing this bit of the stack.

DAMs

It is likely that your project’s assets are saved inside the asset manager of your monolithic CMS. Changing CMS will definitely require you to move them inside a DAM. Each CMS provides its own internal DAM, but you can also consider using a third-party service if you need specific features not offered by the new system.

The following questions will help guide your choice:

• What features do you need?
• What will be the cost of integrating a DAM with your headless CMS? Is there a ready-made integration, or do you have to create one yourself?
• Will you be saving very large videos? If so, will the cost of traffic for videos be acceptable, or is it better to opt for using free platforms such as YouTube?

Storyblok has its own DAM that allows you to upload various types of assets and serve images through a service that manipulates them (e.g. resizing, color change, cropping) and saves them to a CDN.

E-commerce

In the case of an e-commerce project , you can leverage a headless platform that will fit perfectly with your new stack.

These services are API-based, and therefore, they can be used to create seamless omnichannel experiences.

It’s important to check if your CMS already has an official integration for the e-commerce platform you chose, and if not you will have to take into account the cost of creating one.

The vendor lock-in is always around the corner

Vendor lock-in refers to a situation where the cost of switching to a different service provider is so high that the customer cannot transition easily to a different one. With a composable architecture, it is easier not to fall into this problem, but this approach does not guarantee complete immunity. In the implementation phase, you should perform an analysis of the level of vendor lock-in risk with each individual service, so that you can make more informed decisions and be prepared in case you decide to change that part of the stack in the future.