Case Study
View Case StudyTray.ai
Migrating hundreds of thousands of pages, re-platforming and extending for the leading composable AI integration platform
From Tina CMS to Payload
We are the Tina CMS to Payload 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.
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
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 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 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
The self-hosted backend lacks search functionality, Git LFS support, and pagination on reference fields. Large collections can cause network timeouts.
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 Payload
Key advantages
Payload is genuinely strong tech. It’s fast, open-source, developer-first, and perfect if you want full control over your content model. The Next.js integration is smooth, the admin UI is clean, and it’s one of the more flexible modern CMS options if your team prefers to build things exactly the way you want them.
Just know that if you want actual features like visual editing, Vercel Blob storage, image handling, etc, you’ll be paying extra for the privilege. If you’re considering Payload or thinking about migrating into (or out of) it, reach out to us. We can help you figure out whether it’s the right stack or guide you toward a cleaner, saner (Sanity) setup.
Integration with Next.js applications
Payload works natively with Next.js, giving you clean data fetching and a smooth development flow. It removes the usual CMS friction so you can build fast, modern frontends without hacks.
Fully customizable
Everything is configured in code, which means you can tailor the CMS to your exact use case. You define the logic, workflows, and behaviour.
Supports custom data models
You can design any content structure your project needs, from simple documents to complex relational models. This gives you full control over how content is organised and delivered.
Intuitive admin UI
Payload’s admin panel is simple, clean, and fast. Editors can create, update, and manage content without training or digging through confusing menus.
Custom plugins and APIs
You can extend Payload however you like. Build custom fields, integrate external services, or add your own API routes. Perfect for teams that need deeper project-specific functionality.
Built-in authentication
Payload comes with user auth, roles, and access control baked in. No external auth service needed, and you can customise permissions to match your editorial workflow.
Common questions
Tina CMS to Payload migration FAQs
Answers to the most common questions about Tina CMS to Payload 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 hard is it to migrate away from Payload CMS?
Payload stores content in MongoDB or Postgres, so extracting your data is straightforward compared to proprietary platforms. The real work is restructuring your content model for the target CMS and rebuilding any custom access control logic you've written. We typically complete Payload migrations in 3 to 6 weeks depending on how much custom backend logic is involved. The code-first nature of Payload means most of the content model is well-documented in your own codebase, which actually makes migration planning easier.
What are the main reasons teams leave Payload?
The most common reasons we hear are infrastructure fatigue and ecosystem gaps. Payload requires you to manage your own database, hosting, auth, and scaling. Teams that chose Payload for its developer flexibility eventually realise they're spending more time on DevOps than on content features. The Figma acquisition in 2024 also shifted priorities, and some teams feel the platform's direction became less predictable. Visual editing and live preview still require significant custom engineering compared to platforms that ship them natively.
What does a Payload to Sanity migration cost?
For a typical content site with 200 to 1,000 documents, we estimate 4 to 6 weeks of work. The bulk of effort goes into rebuilding the admin experience and frontend integration, not the data transfer itself. Payload's MongoDB exports are clean, so content migration scripts run reliably. The cost depends heavily on how much custom auth logic and access control you've built, since that needs to be rebuilt in the target platform's permission system. We scope every migration individually after reviewing your Payload config.
Get in touch
Fill out the form below and we'll get back to you
