Migrating From TinaCMS
Version 1.2.0
TinaCMS shares Carapace's git-native foundation but takes a different approach to editing: live, visual, on-the-page editing rather than a separate admin form. Worth being upfront about the trade before migrating.
What you'd be giving up
Tina's live visual editing — seeing changes on the actual rendered page as you make them — is a genuinely good editing experience Carapace doesn't offer and isn't trying to replicate. Editing here is conversational: you describe the change, an agent makes it, you review the result. If what your team values most is WYSIWYG, that's a real reason Tina might still be the better fit.
What you'd be gaining
Tina's live editing needs either a self-hosted database-backed indexing layer or Tina Cloud as a hosted service. Carapace needs neither — content is read straight from git at build time, with no indexing service to run or subscribe to. If part of the appeal of a git-based CMS was avoiding extra infrastructure, and the indexing layer has been the exception to that, this removes it entirely.
Both tools already agree that git should be the source of truth. The actual decision is about editing experience — visual and immediate, or conversational — not about the underlying storage model.
The actual migration path
Content is already in git, already reasonably close to Carapace's own model. The main work is converting Tina's content format to the allowlist's HTML subset and moving field configuration into Carapace's simpler per-collection metadata schema. No indexing layer to decommission beyond just stopping its use — nothing carries a standing dependency on it once content is migrated.