Migrating From Strapi
Version 1.2.0
Strapi and Carapace solve a similar-sounding problem — content managed separately from presentation — in genuinely different ways. The migration is less about converting data and more about deciding whether the underlying model actually fits.
The real structural difference
Strapi gives you a database, a REST or GraphQL API, and an admin UI — three pieces of real infrastructure you run and maintain. Carapace has none of them: git replaces the database, an MCP-connected agent replaces the admin UI, and there's no API layer at all. If your Strapi instance is doing real relational work — content types with complex relations, a genuinely large content graph — that's exactly the kind of thing a database is good at and a flat-file store isn't trying to compete with.
What maps over
Strapi's content types map reasonably well to Carapace's collections — each content type becomes a collection with its own metadata fields, same underlying idea. Simple, mostly-text content types (blog posts, docs, pages) migrate cleanly. Content types that lean on Strapi's relational features (many-to-many relations, complex nested components) don't have a direct equivalent — you'd flatten them into simpler per-entry metadata, or decide that content genuinely needs a database and isn't a fit here.
If your team needs a REST or GraphQL API for a separate frontend or mobile app to consume, that's a real Strapi strength Carapace doesn't replace — there's no API layer here by design, not an oversight.
The actual migration path
Export content via Strapi's API, convert entries to the allowlist's HTML subset, and bring them in through the same MCP tools used for everyday writing. Plugin-dependent content types need the most attention — anything relying on custom Strapi plugins doesn't have an automatic equivalent and needs a real decision about what the simplified version looks like.