Tina CMS logo
ButterCMS logo

From Tina CMS to ButterCMS

We are the Tina CMS to ButterCMS migration experts

Last verified:



Challenges with Tina CMS

Key pain points

Tina's biggest limitation is that it's fundamentally tied to the React ecosystem. If you want visual editing, you need a React-based framework like Next.js. Basic content editing works with Astro, Hugo, SvelteKit, and others, but the flagship visual experience is React-only. There's been talk of Vue support for years, but nothing has materialised. This is a hard blocker for agencies like us that work across different tech stacks. The platform has also had a notable history: SSW acquired the project in May 2024, and a security breach in late 2024 involved compromised AWS keys via the CI/CD pipeline. These events, combined with the relatively small community, are worth weighing when evaluating Tina for long-term enterprise projects.

On the practical side, developers report frustrating instability in the dev environment. The admin interface can break without any changes to your codebase because it depends on externally loaded assets that update independently. Error handling is weak — forms fail to save silently, and the GraphQL layer doesn't surface errors cleanly. Self-hosting removes the TinaCloud dependency but comes with its own gaps: no search functionality, no Git LFS support, and reference fields can timeout on large collections.

The editing experience, while impressive in demos, can feel fragile in production. Multiple developers have reported losing work in the editor, and features like branch-based editing are locked behind paid tiers. For agencies managing multiple client projects, the React-only constraint and relatively small community (compared to Sanity, Strapi, or Contentful) mean fewer resources, fewer integrations, and more time spent solving problems yourself.

Help me migrate


React-only framework support in Tina CMS

Visual editing limited to React

TinaCMS supports many frameworks including Astro, Hugo, Jekyll, SvelteKit, and Nuxt for basic content editing. However, the visual/inline editing experience, which is Tina's main selling point, only works with React-based frameworks like Next.js.

Unstable development environment in Tina CMS

Unstable development environment

The dev server can break unpredictably because it loads external assets that change independently of your codebase. This makes local development feel unreliable and hard to debug.

Poor error handling in Tina CMS

Poor error handling and silent failures

Forms can fail to save without any visual indicator, and GraphQL errors aren't surfaced clearly. Losing work without warning is a real risk, especially for content editors.

Branch editing paywall in Tina CMS

Branch editing requires paid tier

Multi-branch support isn't available out of the box — it's locked behind the paid editorial workflow feature. You can't test content changes in deploy previews without paying up.

Self-hosting gaps in Tina CMS

Self-hosting gaps

The self-hosted backend lacks search functionality, Git LFS support, and pagination on reference fields. Large collections can cause network timeouts.

Small ecosystem in Tina CMS

Small ecosystem

Compared to established players like Sanity or Contentful, Tina has a smaller community and fewer plugins. Since the SSW acquisition in May 2024, the project has been actively maintained with regular releases, but the ecosystem is still catching up.



Benefits of ButterCMS

Key advantages

ButterCMS is one of those headless CMS platforms that genuinely nails the onboarding experience. We've seen content teams go from zero to confidently building pages and blog posts within a few hours, which is rare in the headless world. The dashboard is clean, the API explorer is thoughtfully designed, and the starter templates for popular frameworks mean developers aren't starting from scratch every time.

From an agency perspective, the standout quality is how little hand-holding editors need after launch. The interface is intuitive enough that marketers can create pages, manage blog content, and handle SEO metadata without constantly pinging the dev team. The built-in blog engine is a genuine differentiator. Most headless CMS platforms treat blogging as an afterthought, but ButterCMS was originally built around it, and it shows in the quality of the authoring experience.

The API performance is consistently fast, and the SDK support across languages like JavaScript, Python, Ruby, and PHP is solid. Their customer support team is also notably responsive and genuinely receptive to feature requests, which is something we don't often see from CMS vendors. For small-to-mid-sized projects where you need a reliable content API without overcomplicating things, ButterCMS delivers.

We'd particularly recommend it for teams that need a polished blog alongside structured page content, and who value simplicity over infinite extensibility. It's a CMS that knows what it is and does that thing well.

Start my migration


Easy onboarding in ButterCMS

Exceptionally easy onboarding

Content teams can be productive within hours, not days. The dashboard is clean and the learning curve is one of the gentlest we've seen in headless CMS land.

Built-in blog engine in ButterCMS

Built-in blog engine

Unlike most headless platforms where you have to model blog content from scratch, ButterCMS ships with a purpose-built blog engine that includes categories, tags, authors, and SEO fields out of the box.

Fast content API in ButterCMS

Fast and reliable content API

The read API is consistently quick with global CDN delivery. For content-heavy sites, the performance is solid and predictable.

Unlimited seats in ButterCMS

No seat limits on any plan

Every plan includes unlimited users, which is genuinely unusual in this space. You won't get punished for growing your content team.

Responsive support in ButterCMS

Responsive customer support

Their support team is quick to respond and genuinely open to feature requests. We've seen roadmap items added based on customer feedback, which builds real trust.

SDK and framework coverage in ButterCMS

Strong SDK and framework coverage

Official SDKs for JavaScript, Python, Ruby, PHP, and more, plus starter projects for React, Next.js, Vue, Angular, and other frameworks that actually work out of the box.





Common questions

Tina CMS to ButterCMS migration FAQs

Answers to the most common questions about Tina CMS to ButterCMS migration

How do we migrate content out of Tina CMS?
Tina stores content as markdown and MDX files in your Git repository, which makes extraction the easiest part of any CMS migration we do. Your content is already files on disk. The work is in transforming those markdown files into the structured format your new CMS expects. Rich text blocks, custom components embedded in MDX, and frontmatter fields all need mapping. For a blog or docs site with 100 to 500 pages, we typically complete the migration in 2 to 4 weeks.
Why are teams leaving Tina CMS?
Three issues come up repeatedly. First, the React-only constraint for visual editing blocks teams that want to use Astro, SvelteKit, or other frameworks. Second, the development environment is unstable. The admin interface loads external assets that update independently of your codebase, so it can break without you changing anything. Third, the 2024 security breach involving compromised AWS keys shook confidence in the platform's operational maturity. Teams with enterprise compliance requirements found that hard to overlook.
Is it worth self-hosting Tina instead of migrating away?
Self-hosting removes the TinaCloud dependency, but it introduces its own gaps. There's no search functionality, no Git LFS support, and reference fields timeout on large collections. If you're already frustrated with Tina's instability, self-hosting adds more operational burden rather than solving the root problems. We've found that teams considering self-hosted Tina are usually better served by migrating to a platform with proper managed hosting and a more mature editorial experience.
How do we migrate content out of ButterCMS?
ButterCMS has a clean REST API, so pulling your content is straightforward. Blog posts, pages, and collections all export as JSON through their API endpoints. The main complexity is restructuring component-based page content for your target CMS, since ButterCMS components only work on pages and don't map 1:1 to other platforms. Media assets need to be downloaded from their CDN and re-uploaded. For a typical blog-heavy site with 200 to 500 posts, we complete the migration in 2 to 4 weeks.
Why do teams leave ButterCMS?
Content modeling flexibility is the top reason. Once projects grow past simple blogs and marketing pages, the 1,000 content field limit becomes a real ceiling. Components being restricted to pages (not collections or blog posts) forces awkward workarounds. Teams also feel the ecosystem gap, with fewer plugins, integrations, and community resources compared to larger platforms. The 2024 DNS incident that wasn't reflected on their status page raised trust concerns for teams running production sites.
What does ButterCMS cost compared to alternatives?
ButterCMS paid plans start at $71/month after a limited free tier. Every plan includes unlimited users, which is genuinely competitive. But the pricing jumps between tiers aren't proportional to what you get, and the content field limits apply even on expensive plans. By comparison, Sanity's free tier includes 3 users with 500K API requests, and you only pay more as your usage scales. For teams outgrowing ButterCMS, the cost of migration typically pays for itself within 6 months through better tooling and fewer workarounds.


Get in touch

Fill out the form below and we'll get back to you