Headless CMS: Strapi, Directus, Sanity, Contentful, Drupal
Traditional CMS works fine until a designer says "I want scroll animation with parallax," frontend says "we need React," and an SEO specialist says "why is TTFB 3.4 seconds." At that moment, monolithic architecture becomes a problem for everyone.
Headless CMS separates content management from presentation. Editors work in a convenient interface, developers get data through an API and build the frontend on any stack. Sounds simple. In practice, CMS selection, data modeling, and API setup take a significant portion of the project.
Choosing the right tool for the task
There is no universal headless CMS. Choice depends on the team, content complexity, and infrastructure.
Strapi — open-source, self-hosted, Node.js. Suits teams that need control over their data and API customization capabilities. Plugin architecture allows adding custom routes, middleware, lifecycle hooks. REST and GraphQL out of the box. Weak point — Strapi v4 and v5 are incompatible, migration is painful.
Directus — also open-source, but different approach: doesn't generate schema, but wraps an existing database (PostgreSQL, MySQL, SQLite) into REST/GraphQL API. If the database already exists — Directus connects to it without migrations. Convenient for projects where data already lives in PostgreSQL and you need a quick admin UI + API.
Sanity — cloud-based CMS with real-time editor. Distinctive feature — GROQ (Graph-Relational Object Queries), its own query language, more powerful than REST for complex relationships between documents. Portable Text for structured content. Suits media, publishing, marketing sites with non-standard editorial workflows.
Contentful — enterprise cloud CMS. Strong point — localization (up to 1000 locales), rich SDK for all platforms, Contentful Apps for custom UI. Weak point — price when scaling and limited flexibility of data models compared to open-source alternatives.
Drupal — not headless in pure form, but with JSON:API and GraphQL modules turns into a powerful API-first backend. Strong point — maturity (Drupal 10), granular access control, enterprise clients (NASA, weather.com). Entry barrier is high, but for complex government or corporate portals there are few alternatives.
| CMS | Hosting | API | Best scenario |
|---|---|---|---|
| Strapi | Self-hosted / Cloud | REST, GraphQL | Startups, customization |
| Directus | Self-hosted / Cloud | REST, GraphQL | Wrapper over existing DB |
| Sanity | Cloud | GROQ, GraphQL | Media, complex content |
| Contentful | Cloud | REST, GraphQL | Enterprise, localization |
| Drupal | Self-hosted | JSON:API, GraphQL | Government, complex permissions |
How we build projects on headless CMS
Content modeling — critical stage. A mistake here is expensive. Typical mistake: a single body field of type rich text for everything. After half a year, the content manager wants to insert video between paragraphs, add a pull quote with custom styling, embed an interactive table. Rich text doesn't allow this. Solution — Portable Text (Sanity) or custom components in Strapi/Directus through Dynamic Zone.
Frontend. Headless CMS almost always comes with Next.js or Nuxt. For Contentful and Sanity — App Router with ISR: pages are statically generated at build, updated via revalidatePath() when content changes through webhook. For Strapi/Directus with frequent data updates — SSR with cache: 'no-store' or SWR on client.
Case study: corporate site redesign with Strapi + Next.js. Client — manufacturing company, previous site on WordPress with ACF, 200+ pages, 4 languages. Problems: TTFB 3.8s, editors complained about slow admin.
Switched to Strapi 4 (self-hosted on VPS, PostgreSQL), Next.js 14 App Router. Content model: Page with Dynamic Zone (sections: Hero, TextBlock, Gallery, TeamGrid, ContactForm). Localization via Strapi i18n plugin + next-intl on frontend. Frontend deployment on Vercel with ISR, revalidation via Strapi webhook on entry.publish.
TTFB fell from 3.8s to 180ms (static from CDN). Editors got a clean interface without 47 plugins.
Process and timelines
Standard path: audit content needs → data schema → CMS and API setup → frontend development → content migration (if any) → API endpoints testing → deployment.
Migration from WordPress to headless CMS takes as much time as the project itself — often more. Especially if WordPress accumulated custom fields through ACF with non-standard structure.
| Project type | Timeline |
|---|---|
| Simple site on Strapi + Next.js | 4–8 weeks |
| Multilingual corporate site | 8–16 weeks |
| Migration from WordPress to headless | +4–8 weeks to main |
| Drupal enterprise portal | 3–6 months |
Cost — after analyzing requirements and auditing existing infrastructure.







