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 Magnolia
We are the Tina CMS to Magnolia 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 Magnolia
Key advantages
Magnolia shines if you’re the kind of organisation that genuinely needs the full DXP kitchen sink. It packs personalisation, workflows, multi-site orchestration, multilingual publishing, DAM, marketing automation hooks, and every enterprise acronym you can think of. If your teams run complex global content operations with strict governance, Magnolia’s mature permission system, stability, and long-standing enterprise reputation make it a safe, compliant option.
To be transparent, we don’t actually prefer or build with Magnolia (or any of the DXP-flavoured headless CMSs). They try to do everything, and like most jack-of-all-trades platforms, they don’t excel at the things modern teams actually need that is speed, flexibility, clean workflows, and sane pricing. We’d happily point you toward modern alternatives like Sanity that give you 10× the agility without the enterprise bloat.
Java-based enterprise integration
Built on Java, Magnolia plugs neatly into large enterprise stacks that already rely on Java systems and legacy infrastructure. If your organisation lives and breathes JVM, Magnolia won’t fight your architecture.
Secure, scalable architecture
Magnolia’s core is engineered for high-security, high-traffic environments, with strong access control, clustering, and enterprise-grade stability. It’s built to survive heavy editorial activity and large content delivery demands.
Real-time page templating
Editors can adjust components and layouts and immediately preview results, making large enterprise content operations faster and less error-prone.
Editable component previews
Magnolia’s component-level previewing gives editors clarity on how complex pages come together, reducing back-and-forth with developers and keeping multi-team workflows sane.
Multi-site management tools
Designed for global brands, Magnolia supports multiple sites, languages, and regional variations under one roof.
Advanced workflow automation
From multi-step approvals to compliance-driven publishing flows, Magnolia handles heavyweight governance. This is the stuff big enterprises actually need when 20 departments want access but only 2 should publish.
Common questions
Tina CMS to Magnolia migration FAQs
Answers to the most common questions about Tina CMS to Magnolia 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 long does it take to migrate away from Magnolia CMS?
Magnolia migrations are among the most involved we handle. The Java-based architecture, proprietary modules, and tightly coupled workflows mean there's no quick extract-and-import path. Content needs to be exported from Magnolia's JCR (Java Content Repository), transformed, and loaded into your target platform. For a mid-sized enterprise site with 1,000 to 5,000 pages, expect 8 to 16 weeks. The timeline depends heavily on how many proprietary modules your team has adopted and how complex your multi-site setup is.
Why do companies leave Magnolia?
Cost and agility are the two main drivers. Magnolia's enterprise licensing is opaque and expensive, with annual fees that balloon as you add modules and environments. Teams also get frustrated by the Java dependency. Finding and retaining Java CMS developers is harder and more expensive every year, especially when modern headless platforms let teams build with JavaScript and TypeScript instead. The vendor lock-in from proprietary modules makes the decision feel overdue by the time teams finally commit to migrating.
Can we migrate from Magnolia to a headless CMS without losing our multi-site setup?
Yes, but the approach changes. Magnolia handles multi-site through its own orchestration layer, while headless platforms like Sanity use workspace configurations or project-level separation. We rebuild multi-site architectures using the target CMS's native multi-tenancy features. The content migration itself is the simpler part. The harder work is re-implementing your personalisation rules, approval workflows, and permission structures outside of Magnolia's proprietary ecosystem.
Get in touch
Fill out the form below and we'll get back to you
