Headless WordPress or a new headless CMS?

WordPress teams leaving a classic theme have two options. Keep WordPress as the content backend and put Next.js or Astro in front of it. Or move the content into a dedicated headless CMS like Sanity, Payload, or Storyblok. Both work. They solve different problems.

Option 1: keep WordPress, go headless

WordPress has a REST API built in, and the WPGraphQL plugin adds a GraphQL API. Your editors keep the admin they know. The frontend becomes a fast, static or server-rendered site that reads from WordPress.

• Editors don't need retraining
• Content migration is close to zero
• Custom fields from ACF are available through the API

The downsides are less obvious. You still run and patch WordPress. Many plugins stop doing anything useful, because they were built to change the theme's output. Preview needs extra work. And page builder content, like Elementor or Divi layouts, doesn't map cleanly to a frontend.

Option 2: move to a dedicated headless CMS

Here you export posts, pages, custom post types, and media, transform them, and import them into the new CMS. WordPress can export a WXR file from Tools, or you can read everything through the REST API, which is usually cleaner.

• No more WordPress core, theme, or plugin updates
• A content model built for blocks and reuse, not posts and shortcodes
• Live preview, drafts, and roles that work with the new frontend by design

The cost is a full content migration and a new tool for your editors to learn.

How we decide

Whichever you pick, keep the URLs

WordPress permalinks have often been indexed for years. Map them 1:1 if you can. When a slug or category structure changes, add a reviewed 301 for each one. Don't redirect retired posts to the homepage. Send them to the closest relevant page, or let them return 410 if nothing fits.