A headless CMS agency designs the content model, builds or configures a headless CMS, and ships the frontend and integrations that consume its API. We do this for companies leaving WordPress, Drupal or AEM. We build on Payload, Strapi, Sanity, Contentful and Storyblok, migrate your existing content with redirects in place, and support the platform after launch.
If you are still working out what a build, an integration or a migration includes, our headless CMS services page covers the service side. This page is for the next question: which team should do the work, and how.
What does a headless CMS agency do?
Most headless projects come in one of three shapes. Many clients need two of them in sequence: a migration first, then ongoing support.
Build
We set up a new content platform and the frontend that reads from it. On the frontend we usually work in Next.js, sometimes in Astro for content sites that need almost no client-side JavaScript. See our Next.js development and Astro development pages for how we approach each.
Migrate
We move content off WordPress, Drupal or AEM into a headless CMS, with a 301 plan written before any page goes live. Our WordPress to headless CMS migration page describes the most common route, and the headless CMS migration checklist lists every step we check.
Support
After launch we stay on a monthly retainer for schema changes, new templates, upgrades and editor questions. If you would rather extend your own team, you can hire headless CMS developers who work inside your sprints.
When does hiring a headless CMS agency make sense?
An agency is worth the cost when the CMS itself has become the bottleneck. We see three situations again and again:
- You are replatforming off a legacy CMS. Years of plugins, theme overrides and custom code make every change risky. One fintech client ran roughly 40 custom plugins on WordPress before we moved it to Payload.
- You publish to more than one channel. The same campaign has to reach a website, native apps and in-store screens, and editors copy and paste between systems to make that happen.
- Editors wait on developer deploys. A copy change needs a ticket, a review and a release. Marketing ships after the product launch instead of before it.
If none of these apply, read our explainer on what is a headless CMS first. It may be enough to decide you do not need one yet.
When you should not go headless
We turn down headless projects when the fit is wrong. Three cases where we would advise against it:
- A single small brochure site. Five pages that change twice a year do not need an API, a separate frontend and two hosting bills. A traditional CMS or a static site is cheaper to run.
- No developer to own it after launch. A headless setup needs someone to maintain the frontend and the content model. Without that person in house or on a retainer, the site slowly falls behind.
- You need a drag-and-drop page builder and have no budget to add one. Most headless platforms do not ship a visual page builder out of the box. Storyblok comes closest. On the others, a builder is extra work you pay for.
Headless CMS platforms we build on
We do not sell one platform. The table shows where each of the five fits and when we recommend it.
| Platform | Hosting model | Best fit | When we pick it | Our page |
|---|---|---|---|---|
| Payload | Open source (MIT), self-hosted, runs inside a Next.js app | Teams who want the content model in code and in version control | You run Next.js already, want full control of data, and have engineers who will own the schema | Payload CMS services |
| Strapi | Open source, self-hosted or Strapi Cloud | Teams who want an admin panel and APIs fast on Node.js | You need REST or GraphQL quickly, custom plugins, and self-hosting on your own cloud | Strapi development |
| Sanity | SaaS content backend with an open source, customizable Studio | Editorial teams with structured, highly linked content | You need real-time collaboration, flexible content queries and a Studio shaped around your editors | Sanity development |
| Contentful | SaaS | Larger organizations with many spaces, locales and governance rules | You want a managed platform with mature roles, environments and a large app marketplace | Contentful services |
| Storyblok | SaaS with a visual editor | Marketing teams who build pages themselves | Editors need to see and arrange components on the page without asking a developer | Storyblok services |
We also work with Directus, Prismic and headless WordPress when a project calls for them.
How we choose comes down to four questions. What does the content model look like: a few page types, or hundreds of linked entries? Who edits, and do they think in pages or in structured fields? What can you spend on licences, now and at three times today’s traffic? And do you need to self-host for compliance, or is a SaaS vendor acceptable? Our comparison pages walk through the trade-offs in detail: Strapi vs Payload, Strapi vs Sanity, Strapi vs Contentful and Strapi vs Storyblok. If you publish in several languages, our list of multilingual headless CMS platforms narrows the field further.
How we work: from audit to launch
Every project follows the same six steps, and we do not skip the first two even when the deadline is tight.
1. Content and URL audit
We export every URL, content type and integration from your current CMS. We mark which pages rank, which get traffic and which can go. This audit also gives us the numbers we need to price the rest of the project.
2. Content model and platform choice
We design the content model before we pick a platform. The model shows how many types, fields and relations you need, and that usually settles which CMS fits. You sign off on both before we build.
3. Build the CMS and the frontend
We configure the CMS, set up roles and approval states, and build the frontend against real content. In the fintech project, draft, legal review and published states mapped directly to the client’s sign-off process.
4. Migrate content with scripted imports
We write migration scripts that pull content from the old system and normalize it into the new schema. Scripts can run again and again, so we fix mapping errors in code instead of by hand. On large moves we run both systems side by side. The retail group ran old and new in parallel for six weeks before cutover.
5. Redirects, SEO parity and cutover
Every legacy URL maps to a new URL or keeps its path. We carry over titles, descriptions and structured data, then compare the new site page by page against the old one before DNS changes.
6. Handover, training and support
Editors get training on the new workflow. Your developers get documentation of the content model and the deployment setup. Then we either hand over fully or stay on a support retainer.
What a headless CMS project costs
We do not publish a single price, because two headless projects rarely cost the same. The cost depends on a few drivers:
- Content types and templates. Ten page types cost less to model and build than sixty.
- Locales. Each extra language adds translation workflows, fallback rules and testing.
- Integrations. Search, commerce, CRM, analytics and single sign-on each add build and test time.
- Number of editors and roles. More editors usually means more roles, approval states and training.
- Migration volume. How many pages, how messy the source data is, and how many URLs need redirects.
- Licence model. Self-hosted platforms cost hosting and maintenance; SaaS platforms cost a subscription that grows with seats and usage.
We work in four engagement shapes: a fixed-scope audit, a fixed-scope build or migration, a monthly support retainer, or a dedicated team that works inside your process. Every project is scoped after a short audit. The audit gives you a written scope and a price before you commit to the build.
Headless CMS projects we have shipped
All three projects below are anonymized. The figures come from our published case studies.
A US-based Series-B fintech: WordPress to Payload and Next.js
The marketing team needed a developer review for every copy change. We moved the site to Payload with a Next.js frontend and built compliance approval into the CMS. Results: about 65% shorter time to publish, LCP down from 4.2s to 1.4s, full site builds roughly three times faster, and organic traffic held through cutover. Read the fintech replatform case study.
A US-based enterprise multi-brand retail group: five CMSs into one
Five brands ran five legacy CMSs, and editors published the same campaign four or five times. We built one Payload backend that serves Next.js storefronts, React Native apps and in-store screens through a single API. Average publish time fell by about 65%, and seasonal campaigns launch roughly four times faster. Read the omnichannel retail case study.
A European mid-market B2B SaaS: a Payload marketing site
Engineers had to ship every content update. After the Payload build, editors publish on their own: time to publish dropped by about 65% and LCP on the primary landing page went from 4.2s to 1.7s. See the Payload build case study, or browse more work in our headless CMS showcase.
Why Alpina Tech as your headless CMS agency
We work AI-first on the repetitive parts of a CMS project. Models help us draft migration scripts that map legacy fields to the new schema, build redirect maps from URL exports and compare migrated pages against the originals. An engineer reads every script before it touches your content.
Senior engineers do the work. The people who scope your project are the people who build it, so the decisions made in the audit survive into the code.
We have no platform to push. We ship Payload, Strapi, Sanity, Contentful and Storyblok, and the recommendation follows your content model and your budget. Sometimes that means telling you to stay on what you have.
Our migrations protect search traffic. In the fintech replatform, every existing permalink was carried forward and organic traffic held through cutover. The redirect map is a line item in our scope, with its own review before launch.
Talk to a headless CMS team
Tell us what you run today and where you want to go. Book a discovery call and we will come back with the questions a short audit needs to answer. If you already know you need people rather than a project, you can hire headless CMS developers directly.
