How to Migrate From Prismic to a Self-Hosted CMS

Migrating from Prismic is a different job than leaving a website builder. Prismic is already headless — your content is structured JSON behind an API — so you're not rebuilding pages, you're moving structured data from one API to another and repointing your frontend. That makes it cleaner in some ways and trickier in others. Here's how to do it without breaking your live site or your SEO.

Why a headless-to-headless migration is different

Leaving Prismic isn't like leaving Wix. Two things change the game:

1. Your content is already structured. Prismic stores content as documents with typed fields. You can pull it out as JSON via Prismic's API or export tooling. No copy-paste rebuild — it's a data transform.
2. Your frontend does the rendering, not Prismic. Your React/Vue/Svelte app already fetches from Prismic's API and renders it. Migration means changing where that fetch points and remapping the response shape — the templates mostly stay.

The catch: Prismic's content model (slices, groups, rich text as structured JSON) has to be mapped onto your new CMS's model. That mapping is the real work.

The migration plan

1. Export your Prismic content

Pull every document from Prismic as JSON. You can use the Prismic REST/GraphQL API to fetch all documents, or the Migration API / CLI tooling to export in bulk. Save the raw JSON — it's your source of truth. Note your content types (custom types) and how their fields map: title, body/rich text, relationships, and any slices.

2. Decide how to handle slices

This is the key decision. Prismic slices are reusable page sections stored as structured arrays. Your new CMS may not have an equivalent. Two options:

• Flatten slices to HTML/markdown. Render each slice's content into the post body during migration. Simplest — good if the slices were mostly rich text and images.
• Model them as structured content. If you need to keep slices editable as sections, you'll need a CMS with a matching block model. A simpler CMS won't preserve slice structure — flatten instead.

Be honest about which you need. Most blog and article content flattens fine.

3. Set up the target CMS

Choose where content lands. A self-hosted headless CMS like UnfoldCMS keeps content in your own database over a REST API — the last migration you'll be forced into. With UnfoldCMS, one Post model covers posts, pages, and landing content; rich text flattens to the HTML body field, and metadata maps to seo_title and meta_desc.

4. Transform and import

Write a small script that reads your Prismic JSON, maps each field to the target CMS's shape, and creates the content via the target API. Prismic rich text (structured spans) converts to HTML; document relationships become slugs or IDs; slices flatten or map per your step-2 decision. UnfoldCMS accepts writes through its admin API at /api/v1/admin/* (Sanctum token auth), so the import is a loop of authenticated POSTs.

5. Match URLs and set redirects

Your frontend routes may not change at all if you keep the same URL structure — that's the beauty of headless-to-headless. But if slugs or paths change, set 301 redirects for every changed URL so Google carries the ranking forward. UnfoldCMS has a redirect manager at /admin/seo/redirects with CSV bulk import for this.

6. Repoint your frontend

Change your app's fetch layer from Prismic's API to the new CMS's API. Update the base URL, the auth, and the response mapping (field names differ). Because your components already consume structured data, this is mostly an adapter change, not a rewrite. Test every page type against the new endpoints.

7. Verify and cut over

Run the new frontend against the new CMS in staging. Check every content type renders, images resolve, and metadata is intact. Generate and submit a fresh sitemap (UnfoldCMS produces one at /sitemap.xml). Then flip production and monitor Search Console for two to four weeks.

Migration checklist

FAQ

Is migrating from Prismic hard?

It's more of a data transform than a rebuild, because Prismic content is already structured JSON behind an API. The main work is mapping Prismic's model (especially slices) onto your new CMS and repointing your frontend's fetch layer. Blog and article content migrates cleanly; complex slice-based pages take more mapping.

What happens to Prismic slices when I migrate?

Slices are Prismic-specific structured sections. If your target CMS has no equivalent, flatten them into the post body (HTML/markdown) during migration. If you need them to stay editable as sections, you need a CMS with a matching block model. Most content flattens without loss of meaning.

Will migrating from Prismic hurt my SEO?

Not if you keep your URL structure or 301-redirect changed URLs. Since your frontend renders the pages (not Prismic), you can often keep the exact same routes — meaning no URL changes and no SEO risk at all. Where paths do change, redirects carry the ranking forward.

Where should I migrate from Prismic?

To a headless CMS that fits how you'll actually use the content. For self-hosting and owning your data, UnfoldCMS (REST, one-time license) or self-hosted Strapi. If you need to preserve GraphQL or heavy slice structure, weigh Strapi or Directus. Match the target to your slice-handling decision.

The bottom line

Because Prismic is already headless, migrating off it is a structured-data move, not a page rebuild — export the JSON, map the fields, script the import, and repoint your frontend. Keep your URLs or redirect them, and your SEO comes along untouched. Land on a self-hosted CMS and you own the content for good. See the live demo or read up on Prismic alternatives.

Related: Prismic Alternatives · What Is a Headless CMS? · Best Self-Hosted CMS Platforms