Migrate from Storyblok to Strapi: what the move involves
Moving from Storyblok to Strapi is a schema translation, a content transfer and an editor retraining project, and each of the three has its own owner and risk. Storyblok's component model does not map one to one onto Strapi's content types, components and dynamic zones, so the schema work is where most of the design decisions sit. Internal platform and front-end teams usually do this work, often with an implementation partner for the schema design, the import scripts and the preview setup. The effort depends mostly on how many component types, nested blocks, locales and custom field plugins the Storyblok space uses, so the first step is an inventory of those, not an estimate.
Strapi's self-hosted path is MIT-licensed in its Community Edition, which covers the core content API and admin panel you would run yourself. Code under the ee directories falls under the separate Strapi Enterprise Edition license, so confirm with Strapi which features you need from that code, such as SSO for the admin panel or audit logs, before you design around them. Ask your procurement and legal teams to confirm the license terms against the current Strapi LICENSE file rather than relying on this summary.
Plan for the editor side early. Storyblok's visual editor is a hosted, in-context experience that your editors may use daily, and a self-hosted Strapi setup will not reproduce it out of the box. Run a short content audit with the editors who use Storyblok most, identify which preview and publishing workflows they depend on, and agree what replaces each one before cutover. Keep the Storyblok space readable during parallel running so editors can compare old and new entries. Ask any implementation partner to state in writing which parts of the schema, import and preview work are in scope, and what your team must test and sign off.
Which Storyblok capabilities map to Strapi, and which need rework
This table maps each Storyblok capability a team relies on to its nearest Strapi equivalent and marks it clean, needs rework or gap. The visual editor and in-context preview are the main rework area, so plan that work first. Confirm roles, workflow and review features against your Strapi edition on the pricing page before treating them as available.
| Storyblok capability | Strapi equivalent | Status |
|---|---|---|
| Stories and content entries | Collection types and single types with entries managed through the Content Manager | Clean: structure is recreated, then entries are imported |
| Nestable components and component groups | Components and dynamic zones, with groups mapped to component categories | Needs rework: nesting depth and block order must be re-modeled by hand |
| Datasources and option lists | Enumerations, relations or small collection types holding shared option values | Needs rework: each datasource becomes an explicit schema decision |
| Languages and translations | Internationalization (i18n) on content types, with locales defined per field | Needs rework: confirm locale fallback and field-level translation behavior in your version |
| Assets and metadata | Media Library with uploads, folders and alt text fields | Clean for files, needs rework for custom asset metadata and focal points |
| Roles and permissions for editors | Users and Permissions plugin for end users, admin roles in the admin panel | Needs rework: rebuild role scope by hand; export does not carry it over |
| Workflows and approvals | Review workflows and content history, which the pricing page lists by plan | Gap until confirmed: verify availability in your Strapi edition |
| Visual editor and in-context preview | Admin preview and a frontend preview route built by your developers | Needs rework: the main effort area, since editors lose the in-context view |
| REST and GraphQL delivery | REST and GraphQL APIs with the Document Service API and response format changes | Needs rework: client queries and response shapes must be updated |
What to export from Storyblok and what to rebuild by hand
The Storyblok CLI can carry most of your content structure and material into a Strapi project, but roles, workflows, webhooks and preview wiring sit outside that export. Treat each card below as a checkpoint: confirm what the export covers, then plan the work that remains for editors, administrators and developers.
Components and their schema
Pull the component definitions from the Storyblok space first, including groups and presets, because they define the shape of every story you will import. Each Storyblok component becomes either a Strapi component or an entry in a dynamic zone, and nestable components need a decision about which of the two fits. Check that field types such as rich text, options and asset fields have a Strapi equivalent before you write the mapping. Your Strapi schema will be your own code, so keep the exported JSON as the reference for your team.
Stories, versions and published state
Export stories with their content and publish state, then decide which versions matter for the new system. Storyblok stories often hold draft and published content side by side, and Strapi 5 handles drafts and published entries through the Document Service API, so map each story to a single document and confirm which state editors expect to see. Record story slugs and full paths, because links and routing in the front end depend on them. Spot-check a sample of long pages after import.
Datasources and option lists
Datasources hold the option lists that editors pick from in dropdowns and tag fields. Export them with their entries, because a missing datasource often breaks a component silently rather than failing the import. In Strapi, choose between enumerations on the schema, a relation to a collection, or a plain list maintained in code. Confirm with the editorial team who owns each list, since that person will maintain it after cutover.
Languages and localized content
Export the language configuration and every localized version of each story, including the fallback language. Strapi supports internationalization through its own locale settings, so define the locale codes and default locale before importing, and map each Storyblok translation to the matching locale on the same document. Localized slugs and translated assets need their own check. Ask your team which locales go live first, because a partial locale set is easier to verify than a full one.
Assets and asset metadata
The CLI can export asset records with metadata such as alt text, titles and folder placement, but the files themselves must be downloaded and stored in your own bucket or upload provider. Confirm that the asset URLs in the export still resolve before cutover, because a broken image in a migrated story is easy to miss. Decide where files will live (local storage, S3-compatible object storage or another provider) and rewrite asset references during import.
Roles, workflows, webhooks and preview
Roles, workflows, webhooks and preview configuration are not part of the content export, so recreate them by hand. Map each Storyblok role to a Strapi role with explicit permissions, rebuild any approval steps as Strapi review workflows if your plan includes them, and reconnect build hooks that trigger front-end deployments. Preview links must point at your own front end, so budget developer time for that. Write this list down before cutover so no editor discovers a missing step on launch day.
Administrator sign-in and end-user authentication
Strapi SSO applies to administrator sign-in to the admin panel through an identity provider such as Microsoft Azure Active Directory, including auto-registration and a default role. End-user authentication for the site is a separate concern handled by the Users and Permissions plugin. Plan both before cutover, and check whether an optional local login lock-out fits your policy. Confirm SSO availability with your Strapi plan, since the self-hosted pricing page lists it as an add-on on Growth and included in Enterprise.
Target database for Strapi 5
Strapi 5 does not support MongoDB or other NoSQL databases, so the target must be a relational database. Choose PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later, or SQLite 3, and confirm the choice against your hosting and backup standards. Any Node.js runtime you use must be an Active or Maintenance LTS version. Test the import against the chosen database before you run it in production, because schema differences can surface only at that point.
How the Storyblok to Strapi migration runs in five steps
The sequence moves your Storyblok content into Strapi in a controlled order, so each stage produces a checkable output before the next one starts and the old system is retired only after reconciliation.
Inventory the space and map the schema
Your team, with DeployOpen or your own developers, lists every component, nestable component group, story type, datasource, language and asset folder in the Storyblok space. Each Storyblok component is mapped to a Strapi component, a content type or a dynamic zone block, and each field is assigned a Strapi field type. The output is a written schema map that the editorial and engineering leads both sign off. The step is done when every Storyblok component has a named target in Strapi and every open question is recorded.
Export the full space with the Storyblok CLI
Run the Storyblok CLI to pull components, stories, datasources, languages and assets from the space into local files, and download the asset files themselves. Keep this export as a read-only archive. Roles, workflows, scheduled publishing and user accounts are not covered by the content pull, so record those settings by hand from the Storyblok admin. The step is done when you have compared the exported story and asset counts against the Storyblok admin and written down any gaps.
Build and import a pilot content set
Pick one representative story type with nested components, one localized section and some linked assets. Build the matching Strapi components, dynamic zones and locales, then import the pilot with a script that converts Storyblok rich text and asset references into Strapi's format. Review the results on a staging instance with the editors who will use them. The output is a pilot import report listing mapped fields, dropped data and broken references, which drives fixes to the schema map before the full import.
Run both systems in parallel and reconcile
Import the full content set into Strapi while Storyblok continues to serve the live site. Build the front-end to read from Strapi, and set up preview so editors can see drafts in the same app. Compare counts, published states, translations and asset links between the two systems on a schedule until differences are resolved. The step is complete when the reconciliation sign-off names the checks performed, the discrepancies closed and the owner who accepted the remaining risk.
Cut over and archive before decommissioning
Switch the front-end or DNS routing to the Strapi-backed site, and move editors to the Strapi admin panel. Before you change or cancel the Storyblok subscription, confirm that the final archived export is complete, that asset files open and that the export can be stored under your own retention policy. Only then reduce the Storyblok plan or let it lapse. The output is a documented cutover record and an archived export kept on infrastructure you control.
How nestable components map to Strapi components and dynamic zones
The mapping decision is the largest source of rework in this migration, so settle it before any import script is written. In Storyblok, a nestable block is a component that can hold other components in any of its fields, and editors can place it almost anywhere. In Strapi, the equivalent choices are a *component* (a reusable group of fields that a content type embeds, either as a single component or a repeatable one) and a *dynamic zone* (a field that holds an ordered list of different components). For each Storyblok component, decide whether it is a leaf block with only simple fields, a container that nests other blocks, or a page-level block used in mixed lists. Leaf blocks usually become Strapi components. Mixed page bodies, where the editor picks hero, text, gallery and call-to-action blocks in any order, usually become a dynamic zone on the page content type. Nested containers need a check: Strapi components can embed other components, but deep nesting makes the editor and the API harder to reason about, so flatten where the editing experience allows it. Confirm the exact field types and nesting limits against the current Strapi documentation for the version you install.
Component groups and presets in Storyblok are organization features, not data, so they become conventions rather than schema. Use the group names to prefix or folder Strapi component categories, and keep one naming pattern for every component so editors searching the admin panel can find a block by its purpose. Presets, which pre-fill fields for a block, can be recreated as default values where Strapi supports them, or documented as editor guidance if they depend on content. Rich text and asset references need explicit re-linking. Storyblok rich text is stored as a structured document with embedded blocks, so decide whether each embedded block becomes a relation to a Strapi component or a plain field, and write a transform that rewrites asset URLs to the files you imported. Illustrative example: a Storyblok image asset field becomes a Strapi media relation, and the importer replaces each old asset path with the new media ID before the story is saved. Test a sample of pages from every block type and check that links, images and embedded blocks render before you plan the full import.
How the migration changes with team size and starting point
A single space with a handful of component types and one or two languages is the simplest case. Most of the effort sits in translating each nestable component into a Strapi component and deciding where it belongs in a dynamic zone on each page type. Because the content model is small, one developer can usually map, import and verify the full set, and the editor group is typically small enough that training can happen in a single working session with a written walkthrough.
- Mapping effort: Count the component schemas first. If each one maps cleanly to a Strapi component, the schema work stays contained.
- Import scope: Pull stories, assets and datasources with the Storyblok CLI, then compare counts against the Storyblok admin before writing import scripts.
- Parallel run: Keep Storyblok live for editing until the Strapi preview and delivery paths have been checked against real pages. Confirm the length with your own team rather than assuming it.
- Editor training: Document the Strapi admin panel and the new preview flow in a short guide, then watch the first few edits.
- Cost driver: Hosting and the Node.js and database setup usually matter more than the content work at this size.
Before you commit, confirm with your team how many component types and page templates the site really uses, since that count drives most of the timeline.
Many locales multiply the work in every other step. Storyblok stores translated stories and languages in its own structure, and Strapi needs an explicit decision on how localized fields, locale-specific entries and fallbacks are modeled. Mapping effort rises because each component may carry translatable fields in several locales, and the import has to preserve the link between a source story and its translations. Editor training also grows, since each locale may have its own reviewers.
- Locale model: Decide early whether Strapi's internationalization features cover your locales and fallback rules, then test one page end to end in every language.
- Translation links: Verify that imported translations still point to the correct source entries, because broken links are hard to spot in bulk.
- Parallel run: Plan to keep Storyblok open for each locale until its pages and delivery calls have been checked, since locales often finish at different speeds.
- Editor training: Train by locale group, and give translators the same preview access as the editors who publish.
- Cost driver: Storyblok locale pricing matters for the business case, so ask your current account team to confirm how locales are billed before you plan the cutover.
Check that your frontend handles fallback and missing translations the way editors expect before the first locale goes live.
A large estate has many spaces, custom datasources, shared components and several frontends that read from them. The migration becomes a portfolio of smaller migrations, and the dependencies between spaces decide the order. Mapping effort is spread across shared component libraries and datasources that feed navigation, taxonomy or product data. Parallel runs are longer because not every site can move in the same release, and editor training has to cover different roles across departments.
- Dependency map: List which spaces, datasources and frontends reference each other before choosing a sequence.
- Shared components: Design one Strapi component library for shared blocks so that each site does not rebuild the same schema.
- Custom datasources: Identify which datasources are static lists and which are driven by external systems, since the second group needs an integration plan.
- Governance: Decide how Strapi roles, review workflows and audit needs map onto your current access model, and confirm which features your Strapi plan includes.
- Parallel run: Expect staged cutovers per site, with Storyblok kept as the source of truth until each site is signed off.
Ask your team to confirm the full inventory of spaces, datasources and integrations, because an incomplete list is the most common reason a large migration slips.
What drives cost and duration in a Storyblok to Strapi move
The license line is the smallest and easiest part of this move. Strapi's Community Edition is MIT licensed and free, so the recurring software decision is whether you need a paid self-hosted tier. The Strapi self-hosted pricing page lists Growth at 45 US dollars per month including 3 users, with 15 dollars per extra user, and Enterprise on custom pricing. Only Growth includes content history and releases, while SSO for the admin panel is an add-on on Growth and included in Enterprise, and audit logs and review workflows are Enterprise features. If your editors rely on review workflows or audit trails that Storyblok provides today, confirm which tier covers them before you size the project. Strapi Cloud is the hosted alternative, and its listed plans are a separate line item you should compare against your own hosting.
The recurring costs sit in your infrastructure: application hosting for Strapi, a PostgreSQL, MySQL, MariaDB or SQLite database (MongoDB is not supported), a CDN for delivering published content, backups, monitoring, and the Node.js versions that Strapi 5 supports. Those costs rise with traffic and asset volume and fall when you put a CDN in front of the API and asset delivery. The one-time costs are the bigger drivers of duration: rebuilding the front end that consumes Storyblok's delivery API, mapping nestable components to Strapi components and dynamic zones, migrating assets and their metadata, and training editors on the Strapi admin panel. Ask any implementation partner to price each of these separately in the written scope, and ask which of them assume your existing Storyblok components are already documented.
Duration depends mostly on how many component types and locales you have and how much of the front end must be rebuilt. Storyblok's component library, its datasources and its language setup each need a mapping decision, and a large component library will take longer to translate than a small one. Test the content model on a staging Strapi instance before you commit to a date, and agree in writing who signs off on editor preview and content parity. Also plan for parallel running, since content editors will keep working in Storyblok until cutover. Confirm the duration with the vendor, the partner and your own environment rather than relying on a generic estimate.
Cost and effort drivers and how to keep each down
Most of the effort in moving from Storyblok to Strapi comes from the shape of your existing content rather than from the tooling. The cards below cover the drivers that expand the migration and the choices that keep them contained, so you can scope a fixed-price engagement against what you actually have.
Component count and nesting depth
Every Storyblok component and nested block becomes a Strapi component or dynamic zone you must define, test and map. Deeply nested bloks multiply the number of mapping rules, and each level adds a place where stories can fail to import cleanly. Export the component list with the Storyblok CLI, count components per level of nesting, and retire unused components before mapping. Ask for a per-component mapping sheet in any scope you sign.
Number of locales
Each Storyblok language multiplies the content you must transform, verify and keep in sync in Strapi, where localization is handled through the content model. Fallback rules, slugs and translated assets all need checking per locale. Confirm which languages are live, which are stale, and whether any locale exists only as a partial translation. Dropping dormant locales before export reduces both import time and review effort.
Asset volume and metadata
Storyblok assets carry file names, alt text, titles and focal points that editors rely on. Migrating binaries is simple compared with reattaching metadata and rewriting image references inside rich text and stories. Large libraries also raise storage and bandwidth needs on your own hosting. Audit the asset library for duplicates and unused files, decide which metadata must survive, and confirm how your object storage will serve media.
Custom datasource logic
Datasources that power dropdowns or option lists may be simple value lists, or they may depend on logic that lives in your front end or a third-party service. Simple lists move easily into Strapi enumerations or relations. Logic-driven datasources need custom Strapi code, API endpoints and tests, which is development time you pay for once. Inventory every datasource and classify it as static or logic-bound before estimating.
Preview rebuild for editors
Storyblok's visual editor is a hosted feature that Strapi does not provide. Recreating in-context preview means building a preview route in your front end, handling draft versus published content and wiring the editor link. The effort depends on how many page templates need preview and how much of your front end is already server-rendered. Ask any partner to list the templates in scope for preview and to state which editor workflows remain out of scope.
Strapi version choice
Start new work on Strapi 5. Strapi v4 reached end of life on April 30, 2026, so a v4 target would begin with a platform that receives no further updates. Strapi 5 also requires PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later or SQLite 3, and runs only on Active or Maintenance LTS Node.js versions. Confirm your database and Node.js support window before you pick a target, and plan a database backup because downgrading is not supported.
Questions teams ask before moving from Storyblok to Strapi
How long does a migration from Storyblok to Strapi take?
The duration depends on the size and shape of your content model, not on the number of pages alone. The main drivers are how many nestable components and component groups you have, how deeply they nest, how many languages and datasources you run, how much rich text needs translating into Strapi's format, and how many asset files and their metadata must move. Storyblok's own export does not map to Strapi automatically, so the schema translation and the rebuild of preview for editors usually take the most time. No fixed duration applies to every space. Ask any provider to break the estimate into schema mapping, content import, asset transfer, preview rebuild and editor testing, and to state which of these assumes your current content model.
Can our internal team migrate from Storyblok to Strapi without outside help?
Yes, a team with Node.js and TypeScript experience and a clear owner for the content model can do this in-house, and many do. The work needs skills in REST or GraphQL delivery, database administration for PostgreSQL, MySQL, MariaDB or SQLite, and front-end work to rebuild the editor preview. Teams with few developers often find the preview rebuild and the content import script take longer than expected because they are one-off tasks that compete with feature work. Outside help is commonly scoped as a fixed engagement covering one part of the work, such as schema translation or the import pipeline, with the rest kept internal.
What do editors and developers need to do during the move?
Developers own the schema translation, the import scripts, the asset transfer and the new delivery layer. Editors own the sign-off on content accuracy and the workflow they will use in Strapi's admin panel. Expect a short list of decisions from editors before the import, including how to handle draft and published states, which locales carry over, and whether old content types should be archived or removed. Editors should test a staging copy against a checklist of their most common page types. Strapi's admin panel will not reproduce Storyblok's visual editing, so editors need to agree early on what in-context preview they require.
Is the Storyblok export complete enough to move everything?
The Storyblok CLI can pull stories, components with groups and presets, datasources, languages and assets with metadata, but it does not carry over everything a space depends on. Roles, workflows, webhooks, and any settings held only in the Storyblok interface usually need to be recorded and rebuilt by hand. Before you cancel anything, compare record counts for stories, components and assets against the target, spot-check published and draft versions in each language, and confirm that every asset URL resolves after the move. Keep a full copy of the export under your own control so you can rerun the import if the schema changes.
What license applies to Strapi Enterprise Edition code?
Strapi's Community Edition is under the MIT Expat license, but code in directories named ee is under the separate Strapi Enterprise Edition license. That code can be used only if your organization has a signed agreement with Strapi or holds a Strapi Cloud subscription. Your legal team should confirm which features you need before the build starts. Admin single sign-on, audit logs and review workflows are Enterprise features on the self-hosted pricing page, so if your governance requirements depend on them, plan for the Enterprise license or find an alternative for those controls. Check the LICENSE file in the version you deploy, because the boundary is defined there.
Can Strapi 5 run on MongoDB?
No. Strapi 5 does not support MongoDB or other NoSQL databases. Its supported databases are PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3. If your current stack or team standards depend on MongoDB, choose PostgreSQL or MySQL for the Strapi database before you start the schema work, and plan the data transfer accordingly. Also confirm that your hosting runs only on Active or Maintenance LTS Node.js versions, which Strapi 5 requires.
What should a migration quote include?
A quote should follow from a written scope that lists the work in separate lines. Ask for the schema mapping of each Storyblok component to a Strapi component or dynamic zone, the import plan for stories, datasources, languages and assets, the preview rebuild for editors, the environment setup including database and hosting, a testing and cutover plan, and the handover documentation. Ask which items are one-time and which recur, such as hosting, backups, upgrades and support. DeployOpen plans, implements, integrates, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts.
Does moving to self-hosted Strapi remove our Storyblok subscription costs?
It changes the cost structure rather than removing cost. Storyblok fees are tied to plan, seats, locales, API requests and traffic. Self-hosted Strapi's Community Edition has no license fee, but you pay for hosting, the database, storage, bandwidth, backups, monitoring, upgrades and the people who run them. Growth and Enterprise plans for Strapi add paid features, and Strapi Cloud is a separate hosted option with its own plan prices. Build a comparison that lists each component, marks which costs are one-time and which recur, and states what changes the total as your traffic and editor count grow.
How DeployOpen scopes and runs a Storyblok to Strapi migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For a Storyblok to Strapi move, that means the Strapi instance, its database, the editor-facing admin panel, the front-end delivery layer and the backup routine are built in your environment, not on a DeployOpen-hosted tenant. Most engagements are fixed-scope, so the written scope is where the decisions get made before any data moves: which Storyblok spaces and languages are in scope, which component families map to Strapi components and which to dynamic zones, how assets are handled, and who signs off on the cutover. Ask for the scope to name each of these items explicitly, because the wording of the scope determines the deliverables and the acceptance checks.
A quote follows from that written scope, so the cost you are asked to approve reflects the deliverables you agreed to. Ask the scope to separate the one-time work (schema translation, the import of stories and assets, preview setup for editors, parallel-run testing and cutover) from the recurring work (hosting, database backups, Strapi upgrades and monitoring). Strapi's own pricing and version history matter here: the self-hosted plans and their feature gates, such as SSO and content history, are listed on Strapi's self-hosted pricing page, and the scope should state which tier the project assumes. Ongoing support, upgrades and continuous testing are available as retainers, which suits teams that want a named party to apply Strapi releases, which ship frequently, and to keep the database backup and restore process tested. Confirm the retainer scope in writing as well, including what is excluded from it.
