How to Migrate From ButterCMS to a Self-Hosted CMS

ButterCMS is a hosted, API-first CMS that's quick to start with — a blog engine and content API without running a server. The reasons to leave are the usual SaaS ones: subscription cost that climbs with usage, content living on Butter's servers, API rate limits, and no self-hosting option. Migrating off ButterCMS is straightforward because its API is clean and REST-based. This guide walks the move to a self-hosted CMS with SEO intact.

TL;DR: Export ButterCMS content via its REST API, map posts and pages, import into a self-hosted CMS like UnfoldCMS, preserve slugs, set up 301 redirects for changed URLs, and repoint your front end. Both sides are REST, so the front-end rewrite is light.

Why migrate off ButterCMS?

Pin down your reason:

• Subscription cost. Hosted pricing rises with usage, seats, and API calls. Predictable early, less so at scale.
• Data ownership. Content lives on Butter's platform. A self-hosted CMS puts it in your own database. See data ownership and your CMS.
• No self-hosting. ButterCMS is SaaS-only. If "on our infrastructure" is required, you must move.
• API limits. You're metered on requests — a constraint for high-traffic or build-heavy sites.

If Butter's convenience is worth the fee, staying is fine. If ownership or cost drives you, read on.

What you're moving to

This guide targets UnfoldCMS, a self-hosted CMS on Laravel with a REST API at /api/v1/*, content in your own SQLite or MySQL database, and a one-time cost. Because both ButterCMS and UnfoldCMS are REST-based, the front-end rewrite is light — mostly changing endpoints and adjusting the response shape, not a GraphQL-to-REST overhaul.

Step 1 — Export from ButterCMS

ButterCMS exposes content through its REST API. Pull all blog posts:

curl "https://api.buttercms.com/v2/posts/?auth_token=YOUR_TOKEN&page_size=100&page=1"

Page through until you have every post. Each returns clean JSON with title, slug, body (HTML), summary, seo_title, meta_description, published, and any custom fields. ButterCMS also has "Pages" and "Collections" — pull those with their respective endpoints. Download referenced images to rehost.

Step 2 — Map to posts and pages

ButterCMS content maps cleanly to a content-first CMS:

Butter's model is flat and blog-oriented, so this mapping is quick — no nested block tree to flatten.

Step 3 — Body format

ButterCMS's WYSIWYG outputs HTML, which drops straight into UnfoldCMS (it stores body as HTML). Verify a few posts — check headings, links, and images survive. If any content is markdown, convert on import.

Step 4 — Import into the CMS

Write a migration script that reads your Butter export and creates a post or page per entry. Preserve slugs for SEO, set posted_at from the published date to keep chronology, map seo_title/meta_description to the SEO fields, and attach images to the media library. Both sides being REST, the read-transform-write loop scripts cleanly.

Step 5 — Preserve SEO with redirects

If URLs change, set up 301 redirects from old to new paths. UnfoldCMS ships a redirects system. Preserve slugs to keep most URLs identical and redirects minimal — but audit every path. This protects rankings; don't skip it. See migrate a blog without losing SEO.

Because you exported seo_title and meta_description, your per-post SEO carries over directly — a real advantage of ButterCMS's structured export.

Step 6 — Repoint your front end

Your front end calls Butter's REST API. Update it to call UnfoldCMS's REST API and adjust the response mapping — read data.data from the { success, message, data } envelope instead of Butter's data.posts array:

// Before (ButterCMS)
const res = await fetch(`${BUTTER}/posts/?auth_token=KEY`);
const { data: posts } = await res.json();  // Butter nests under data

// After (UnfoldCMS)
const res = await fetch('https://cms.yoursite.com/api/v1/posts?per_page=20');
const { data: posts } = await res.json();

Both REST with similar shapes — a light change, not a rewrite.

Step 7 — Rebuild-on-publish

If Butter webhooks triggered rebuilds, replicate with UnfoldCMS's outgoing HMAC-signed webhooks pointed at your deploy hook. Publishing fires the rebuild — same flow, self-hosted.

Migration checklist

• [ ] Export posts, pages, and collections via REST
• [ ] Download referenced images
• [ ] Map to posts and pages
• [ ] Confirm body is HTML (usually)
• [ ] Import content, preserving slugs, dates, and SEO fields
• [ ] Attach images to the media library
• [ ] Set up 301 redirects for any changed URLs
• [ ] Repoint front-end API calls (light — REST to REST)
• [ ] Replicate rebuild webhooks
• [ ] Verify sample pages before go-live

FAQ

Can I export my content from ButterCMS? Yes. Butter's REST API returns every post, page, and collection with all fields — including SEO title and meta description — and images are downloadable. You get a full, exportable copy.

Will I lose SEO migrating off ButterCMS? Not if you preserve slugs, set up 301 redirects for changed URLs, and carry over the exported seo_title/meta_description to the new CMS's SEO fields.

Is migrating off ButterCMS hard? It's one of the easier migrations. Butter's content is flat, REST, HTML-bodied, and includes SEO fields — so both export and the front-end change are light. The main work is mapping and importing.

Do I have to rewrite my front end? Only lightly. Both Butter and UnfoldCMS are REST APIs — you change endpoints and adjust the response shape, no GraphQL-to-REST rewrite.

Bottom line

Migrating off ButterCMS is one of the smoother CMS moves: export via REST (SEO fields included), map to posts and pages, import into a self-hosted CMS, and protect rankings with redirects. Because both Butter and UnfoldCMS are REST-based, the front-end change is minor. You gain data ownership and drop the subscription with little friction.

See UnfoldCMS in the demo or read ButterCMS alternatives.

Related: ButterCMS alternatives · How to migrate a blog without losing SEO · Self-hosted vs SaaS CMS