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 Uniform
We are the Tina CMS to Uniform 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 Uniform
Key advantages
Uniform positions itself as a “composable DXP,” which is enterprise-speak for “it does a bit of everything on top of your actual CMS.” To be fair, the visual workspace is genuinely useful. Marketers get drag-and-drop control, personalization, and A/B testing without pinging developers every five minutes. And if you’re already juggling multiple systems (CMS, commerce, DAM), the orchestration layer can tidy up the chaos.
That said… we’ll be honest, we don’t really build with DXPs like this anymore. Whenever a headless tool starts shouting “DXP” from the homepage, it usually means heavyweight architecture, unnecessary complexity, and a bill only Fortune 500 companies would smile at. If you’re considering it anyway, feel free to get in touch. We’ll happily walk you through better, modern alternatives before you sink a quarter’s budget into something you probably don’t need.
Visual experience composition
Uniform’s visual builder lets marketers piece together pages without pinging developers every 5 minutes. It’s basically a drag-and-drop layer on top of your headless stack.
Multi-source content federation
Uniform pulls content from multiple CMSs, DAMs, and commerce tools into one interface, so you don’t need 10 tabs open to build a single page
Real-time collaboration tools
Teams can edit, plan, and experiment together without overwriting each other’s work. It’s built for big organisations where ten people touching the same page is a weekly occurrence.
Enterprise-grade scalability
Uniform is built to handle traffic spikes and heavy personalisation workloads. It’s overkill for small sites but a safe bet for enterprises terrified of a Black Friday outage.
Omnichannel content management
You can pipe the same content across web, apps, and any other channel marketing dreams up. Useful for brands juggling multiple experiences without wanting to rebuild the same page three times.
Built-in A/B testing
Uniform ships with native testing and targeting, so teams can experiment without gluing together half a dozen tools. It’s marketer-friendly and fast.
Common questions
Tina CMS to Uniform migration FAQs
Answers to the most common questions about Tina CMS to Uniform 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 away from Uniform?
Uniform is an orchestration layer, not a traditional CMS, so migration means detangling it from the systems it sits on top of. Your actual content likely lives in a separate CMS, DAM, or commerce platform. The Uniform-specific parts, including composition layouts, personalisation rules, and A/B test configurations, need to be rebuilt in your target platform or replaced with dedicated tools. We typically spend 2 to 4 weeks on Uniform-specific teardown, on top of whatever migration the underlying content sources require.
Why do teams leave Uniform?
The price-to-value ratio is the most common complaint. Uniform's enterprise pricing is steep, and teams find they're paying premium rates for an abstraction layer that adds complexity rather than removing it. The learning curve is real. Teams consistently need weeks of onboarding to become productive, and the orchestration model introduces debugging overhead that frustrates both developers and content editors. When the contract comes up for renewal, many teams conclude they'd be better served by a simpler architecture.
Do we actually need a DXP like Uniform?
Probably not. We've worked with teams that adopted Uniform because they were managing content across 4 or 5 different systems and wanted a single editing interface. In practice, most of those teams would have been better off consolidating into one strong headless CMS and using it as the single source of truth. The "composable DXP" pitch sounds good in a sales deck, but it often means you're paying enterprise prices to glue together tools that could be replaced by a cleaner architecture. We're happy to audit your stack and give you an honest answer.
Get in touch
Fill out the form below and we'll get back to you
