How to export your data from Storyblok

How to export your data from Storyblok before you leave

The Storyblok CLI can pull a space's content model and content, but users, roles, workflows and delivery settings do not come with it, so they must be rebuilt by hand. If your renewal, a pricing change or a residency requirement is pushing you off Storyblok, start by listing what the export carries and what your editors and developers depend on outside the space. In practice, the content side covers stories, components with their groups and presets, datasources, languages and assets with their metadata. The operational side (who can edit what, approval steps, access tokens, API and webhook settings, and preview configuration) sits outside that content model and has to be documented before you turn anything off.

Before you run any export, confirm the exact command names, flags, and output formats against Storyblok's current CLI documentation, because the CLI changes and this page does not reproduce its syntax. Ask your Storyblok contact or check the official docs for which resources the CLI can export for your plan, whether asset files are downloaded or only their URLs and metadata, and how multiple languages and nested components are represented in the output. Also confirm whether you can export a space from a role that has read access without administrator rights, since your migration team may not hold the owner role.

Treat the export as a draft until it is verified. Keep a dated copy of the raw output, compare story and component counts per space against the Storyblok interface, spot-check a sample of entries in each language, and confirm that every asset referenced in content has a file or a working URL in your archive. Record roles, workflows and API token scopes in a separate inventory, since those have to be recreated in the new system. Once the inventory is complete, the next step is mapping the exported schema to your target platform.

What the Storyblok CLI exports and in what format

This table lists each Storyblok data type you need to carry out of the space and what to confirm for it. Where the command, file format or limit is not stated in the official Storyblok CLI reference, check it there or run the export on a test space before you rely on it. The main takeaway is that content, schema and assets each need their own check, and roles and workflows need manual records.

Data type	Export method	Output format and limits
Stories	Confirm the CLI command that pulls stories and whether it includes drafts and published versions	Confirm the file format and whether nested component content is included
Components with groups and presets	Confirm whether the CLI pulls component schemas, groups and presets together	Check that presets and group membership appear alongside field definitions
Datasources	Confirm the export command and whether datasource entries are included	Check that datasource values survive the export in a test space
Languages	Confirm whether the CLI exports language settings or only content per locale	Check that each locale's stories are present and labeled correctly
Assets with metadata	Confirm whether the CLI downloads binary files or only asset records	Check alt text, titles and folder paths in the exported files
Roles, workflows and space settings	Not expected in content exports, so confirm in the CLI reference	Record current roles and workflows by hand before you leave

What does not come out of Storyblok and how to rebuild it

A Storyblok CLI pull carries content and schema, but operational state lives in the admin layer: people, permissions, approval paths, publishing state and integrations. Each item below needs a deliberate rebuild in the new CMS, and each should be confirmed against the current Storyblok documentation before you rely on it.

User accounts and passwords

Editor and admin accounts, their invitations and their passwords are not part of a content export, and passwords cannot be extracted in readable form. Plan to recreate every editor in Strapi or Payload, then decide whether end-user accounts for a customer-facing site exist at all. Export the user list from Storyblok's admin area so you have a checklist to work through. Confirm with Storyblok which user fields are available for export before you assume a complete list.

Roles and permissions

Space roles, per-folder or per-component restrictions and the rights each editor holds are configuration in the Storyblok admin, not content. Write down who can edit, publish and manage schema before you migrate, and map each role to a Strapi role or Payload access control rule. Illustrative example: a regional editor limited to one language folder needs a matching field-level or document-level rule in the new CMS, which has to be written and tested by hand.

Workflows and approval steps

Any review, approval or publishing sequence configured in Storyblok lives in its workflow settings, not in the stories. Document each step, who signs off, and which states trigger a notification. Strapi offers review workflows on its Enterprise edition, so confirm whether you need that tier or whether a simpler status field and hooks will do. Payload would use custom fields, access rules and hooks. Either way, the approval logic must be rebuilt and tested.

Published versus draft state

A content export shows story content, but it may not preserve which version is live, which draft is pending, or the scheduled publish dates that editors set. Before cutover, compare a sample of published stories with their live URLs in Storyblok and confirm that your import sets the same published state. Confirm how the CLI handles unpublished changes and scheduled releases in the current docs, because the answer determines whether your front end can show the right content on day one.

Webhooks, access tokens and integrations

Webhooks that trigger builds or cache purges, preview tokens, Management API tokens and the Content Delivery API tokens your front end uses are all configured outside the content. Inventory every token and webhook, rotate the credentials, and point your front end and build pipeline at the new CMS. Tokens exported from one system should never be reused in another. Confirm the current token types and webhook events in Storyblok's documentation.

Space settings and language configuration

Space-level settings such as the default language, the space name, domain and asset configuration are not all stored as content. Record each setting from the Storyblok admin, then confirm which ones the CLI carries over. Language codes, fallback chains and default locales must be recreated in the new CMS, since Strapi and Payload define localization in their own configuration. Check that every language code used by stories matches the locale definition in the target system before you import.

How to export your data from Storyblok step by step

This sequence takes you from access checks to a verified copy of your Storyblok space that you hold in storage you control. It covers what the CLI can pull, the inventory you record by hand, and the checks that show the export is complete. Run it on a test space first, and keep the export outside Storyblok before any renewal deadline.

Confirm access and snapshot the space
Confirm that the person running the export holds an admin or owner role on the Storyblok space, that the Storyblok CLI is installed at a version you have checked against the current Storyblok documentation, and that your access token works against the space. Then export the space into a dated working folder and note the space name, space ID and export date. Run this full sequence on a test space first so you learn what the CLI carries before the real export. Output: a short log of the account, CLI version and snapshot date.
Pull components, groups and datasources
Export the component schemas with their groups and presets, then export the datasources that hold the option lists editors choose from. Keep the JSON exactly as the CLI delivers it and avoid hand edits, so the schema matches what the space holds. Check that every component a story uses appears in the export, including nestable components placed inside other components. List anything you configured in the interface that the export may not carry, such as custom field plugins, so it goes onto the rebuild checklist. Output: a component inventory and datasource files you can compare against a later export.
Pull stories in every language
Export stories for each language your space uses, including the default language, and take the language codes from the space settings so none is missed. Confirm that folders, slugs and the published or draft state are captured, and note any story that exists only as a draft. Compare the story count for each language against the count you see in the interface for a sample of folders. Output: story files for each language and a count sheet to keep with the export.
Download assets with metadata
Download the asset files and the metadata that accompanies them, such as titles, alt text and folder placement, to the extent the CLI includes them. Assets are where exports most often fail without warning, so compare the number of files on disk with the asset count in the space and record every failed download by asset ID. Keep the original files rather than only the optimized renditions served through the CDN, and confirm with Storyblok which renditions the CLI includes. Output: an asset folder, a metadata file and a failure list.
Record users, roles and workflows by hand
The CLI does not cover everything, so write down users, their roles, space permissions, workflow stages and approval rules from the Storyblok settings screens. Capture screenshots on the same day as the export and note who owns each content area. Also list the integrations and webhooks that call the space, because those must be rebuilt in the new system. Ask Storyblok to confirm, for your plan, which of these items the CLI does not carry. Output: a reviewed inventory that becomes the rebuild checklist for the new platform.
Store the export in controlled storage
Move the working folder into storage you control, such as an object store or a private Git repository, with versioning or immutable snapshots enabled. Limit read access to the migration team, because the export contains unpublished content, user records and asset files. Write a checksum for each file into a manifest so later copies can be compared against the original. Keep the Storyblok space live until verification passes, and complete this step before any renewal or cancellation date in your contract. Output: a versioned archive with a manifest and a current access list.
Verify the export is complete
Compare the export against the inventory from the earlier steps, covering component count, datasource count, story count for each language, asset count and the failure list. Re-run the export on the test space and diff the two outputs, then open a sample of exported stories beside the live space to check content and structure. Recompute the checksums after the copy to storage and confirm they match the manifest. Name one owner to sign off. Output: a verification report listing every mismatch and its resolution, and the export counts as complete only when no mismatch is open.

How to verify the export is complete

Count stories and components per language in Storyblok, then match those counts against the export files before you consider the export complete. Open the space in the Storyblok web app, note the number of stories for each language and the number of components in the component library, and record them with the export date. Then count the story JSON files and component definitions the CLI wrote to disk, and compare language by language. A mismatch in one language usually points to a missing locale setting or a story left in an unpublished state, so resolve it before moving on. Do not rely on a total alone, because two errors can cancel each other out.

Next, check that every asset referenced by a story exists locally with its metadata. Pick the story JSON fields that point to images, video and files, collect the asset identifiers, and confirm each one has a file on disk and a matching metadata record covering filename, alt text, title and dimensions where Storyblok supplied them. Missing files often trace back to assets that returned an access error during download, so log those failures and re-pull them rather than assuming they are harmless. Spot-check rich text fields and component presets on a sample of stories, comparing the exported JSON with what the editor shows, including nested blocks and datasource values that stories reference.

Finally, restore the export into a test instance of the target CMS, such as a local Strapi or Payload install, and confirm that content loads, relations resolve and assets render. Treat this as the real test, since a file can be complete and still be unusable by the importer. Record the counts, file checksums and the restore result on the day of export and store them with the archive, along with the CLI version used. Confirm with your Storyblok account team which roles, workflows and release history the CLI does not return, because those will need manual documentation.

Where the exported data lands in Strapi or Payload

Strapi 5 is a Node.js application with its own content type model, so exported Storyblok components and stories must be translated into Strapi content types, components and dynamic zones before any content loads. Storyblok's nestable components map most naturally to Strapi components and dynamic zones, and the data itself is stored in a relational database. Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3. It does not support MongoDB or other NoSQL databases, and it runs only on Active or Maintenance LTS Node.js versions.

Relational database choice: Pick PostgreSQL, MySQL, MariaDB or SQLite from the supported list. A Storyblok export that you plan to load into MongoDB will need a different target.
Schema translation: Each exported component becomes a Strapi component or content type, and each nestable component slot becomes a dynamic zone or repeatable component field.
Node.js runtime: Run Strapi only on a Node.js version that is Active or Maintenance LTS at the time of deployment, not on an end-of-life release.
Asset and locale handling: Plan where downloaded asset files and their metadata will be stored, and how each Storyblok language maps to Strapi internationalization.
Backups before import: Take a database backup before loading any export, since the Strapi migration docs say downgrading is not supported.

Confirm the current database and Node.js requirements in the Strapi installation docs before choosing your database and runtime.

Payload defines collections, fields and blocks in TypeScript code that lives inside a Next.js application, so exported Storyblok schemas must be rewritten as code-defined config rather than imported as a schema file. Payload supports MongoDB, PostgreSQL and SQLite, which gives teams with an existing document database a path that Strapi does not offer. Payload generates TypeScript types automatically from those collections and fields, so the converted schema also becomes the source of truth for your front-end types.

Database choice: Select MongoDB, PostgreSQL or SQLite. Teams already running MongoDB can keep their operational tooling, while PostgreSQL suits teams that want a relational store.
Collections and blocks: Turn each Storyblok content type into a collection and each component into a block in the layout builder, writing the field definitions by hand or with a generation script.
Typed output: Once collections are defined, Payload generates TypeScript types, so the import script and the front end can be checked against the same schema.
Rich text and assets: Storyblok rich text must be converted into the Lexical editor format, and asset files must be stored in a location your Payload instance can serve.
Next.js hosting: Because Payload installs into a Next.js /app folder, the database and the application runtime both need to be sized and backed up as one system.

Confirm the supported databases and hosting options in the Payload repository before you choose, since the project's release line is changing.

What to plan before the Storyblok renewal or termination

Leaving Storyblok is a sequence of decisions, and most of them have to be made before the notice date rather than after it. The cards below cover the export timeline, the target platform, data ownership after termination, keeping delivery live during cutover, the effort of rebuilding roles and workflows, and the contract terms that govern your data.

Set the export and verification timeline

Work backward from your contract end date and schedule a full CLI export, a test import into the target platform and a comparison of story counts, asset counts and component schemas. Plan at least one repeat export close to cutover, because editors keep changing content until the switch. Ask your team which stories are published, which are drafts and which are scheduled, since each state needs a check.

Choose the target platform first

The export format you need depends on whether you are moving to Strapi or Payload. Strapi 5 requires PostgreSQL, MySQL, MariaDB or SQLite and does not support MongoDB, while Payload also supports MongoDB and SQLite and installs into a Next.js app. Decide the database, hosting model and editing experience before you pull components, because that decision determines how nestable components map to content types or blocks.

Settle who owns the archive after termination

Confirm in writing who keeps the exported JSON, the asset files and any backups after your subscription ends, and for how long. Ask whether the vendor retains copies of your content, and on what schedule it deletes them. Store the archive in storage you control, with versioned copies, so a later audit or legal request does not depend on a closed account.

Keep delivery running during cutover

Your websites and apps likely fetch content through the Storyblok content delivery API, so the frontend must switch sources without a gap. Plan a parallel run where the new CMS serves a staging frontend, and define a rollback path that points the production frontend back to Storyblok. Agree the freeze window with editors so no content is created in one system while the other is live.

Budget for rebuilding roles and workflows

The CLI export does not carry over user roles, permissions, approval workflows or space-level settings, so these must be recreated by hand in the target CMS. Inventory who can publish, who approves translations and which workflow steps exist today. Budget for this as a one-time task with a named owner, since it touches access control and audit evidence, and document each rebuilt rule.

Check the contract for data return terms

Read your Storyblok agreement for clauses on data export, return, retention and deletion, and note any notice period that controls when the service ends. Confirm the notice date with the vendor in writing rather than relying on a renewal reminder. Ask whether an export is available after termination and whether it costs extra, and get the answer in writing before you sign any new commitment.

Can your team export your data from Storyblok without outside help?

Is the Storyblok CLI alone enough to export everything from a space?

The CLI covers the content side of a migration: stories, components with their groups and presets, datasources, languages and assets with their metadata. It does not cover everything you need to run the site afterward. Roles, permissions, workflow or approval steps, and other team settings have to be recorded and rebuilt by hand. Before you rely on the CLI, confirm the exact commands and options for your CLI version against Storyblok's current documentation, and run a test export on a copy of the space so you can see what arrives in the output. Treat that test as the first step of the migration plan, not a separate task.

How long does a full Storyblok export and verification take?

No general duration has been established for this work, so ask for an estimate tied to your own space. The main drivers are the number of stories and their version history, the number of components and how deeply they nest, the number of locales each story must be exported in, and the volume and size of assets. Verification adds time in proportion to how thoroughly you check, from counting records to rendering sample pages in a staging front end. Ask the provider to state the assumptions behind its estimate, including the number of spaces, the verification method and the number of review rounds.

What does our team need to provide for an export?

You need an administrator login to the source space with enough rights to read components, datasources, languages and assets. You also need a test or sandbox space where exports can be trialed without touching production content. Someone on your side should understand the component schema well enough to say which components are shared, which are deprecated and which only exist for one page template. Finally, you need a named owner for editorial sign-off, because someone who uses the content daily will spot problems that a record count cannot. Agree access and these owners in writing before the work begins.

How does the cost of an export depend on components, locales and assets?

The cost comes from people's time, not from the export tool itself. Component count drives the work of mapping each schema into a target content model. Locales multiply the number of content variants to move and test, and they affect routing and fallback rules in the new front end. Assets drive the time to download, check and re-link files, and the storage and transfer they need on your own hosting. Your Storyblok subscription fees are separate and continue until you cancel, so check your current plan terms. If you compare with a self-hosted target, Strapi publishes self-hosted pricing for its plans, but your infrastructure, database and maintenance costs still need their own estimate. Ask every quote to itemize these drivers.

What has to be rebuilt by hand after exporting from Storyblok?

Expect to rebuild anything that lives in the space settings or the editing workflow rather than in the content itself. In practice this means user roles and permissions, any workflow or approval steps editors rely on, the visual editor configuration, preview links and any integrations or webhooks that feed other systems. Record each of these from the source space before you export, because the CLI output will not give you a complete list of them. Then decide which ones your target platform should reproduce, and which ones editors should accept changing. Setting up preview is often the largest piece, because it depends on how the new front end renders content.

How do we verify that a Storyblok export is complete?

Verify by comparison, not by trust. Count stories, components, datasources, languages and asset files in the source space, then compare each count with the exported data and the imported target. Check that asset files download and match the metadata recorded for them, and spot-check that links between stories still resolve. Compare published and draft versions of a sample of stories, and render the most important templates in a staging front end for each locale. Keep the comparison reports as evidence. Ask the provider to show its verification method and to sign off a defined set of checks before you approve the cutover.

What should a written scope for a Storyblok export include?

A written scope should list the spaces in scope, the content types and locales included, and the assets covered. It should name the target platform and state what is excluded, such as historical versions or unused components. Include an inventory of settings to be rebuilt, the acceptance checks and who signs them off, and the access and data handling rules for the source and the working copies. Add the environments involved, the change freeze period for editors, and what happens if verification fails. DeployOpen typically agrees scope, deliverables and timelines in writing before work starts, and ongoing support can be arranged as a retainer after go-live.

Can a smaller team run the Storyblok export itself?

A small team with a simple space can often run the export internally, provided it has an administrator, a sandbox space and a person who understands the component schema. The work gets harder as the number of locales, components and assets grows, and when preview, roles and integrations must be rebuilt in the same window. Internal teams also tend to underestimate verification, which is where most surprises appear. A practical approach is to run a test export yourself, count what you get, and then decide whether the remaining work fits your team's capacity. If it does not, a fixed-scope engagement can cover the parts you choose to hand over.

How DeployOpen scopes and delivers a Storyblok exit

DeployOpen plans and implements the self-hosted platform that receives your Storyblok content, and treats the export as a verified deliverable rather than a single command. We work inside your own cloud accounts, data centers or air-gapped networks, and agree the scope in writing before any export work begins.

How we scope

Written scope lists which spaces, languages, component groups, datasources and asset folders leave Storyblok.
We inventory roles, workflows and webhooks that must be rebuilt by hand on the new platform.
Engagements are fixed-scope, and ongoing support is available as a retainer after handover.

How we build

We run the Storyblok CLI export into version-controlled files and keep a dated copy of each pull.
We map exported components and datasources to the target schema and import stories and assets in test first.
We test the restored content against the source space, checking counts, locales, asset metadata and sample pages.

How we hand over

You receive the export archives, mapping documentation, and a reconciliation report showing what matched and what did not.
A checklist lists manual rebuilds such as editor roles, approval workflows and preview setup with owners named.
We document the backup and restore procedure for the self-hosted CMS database and asset store.

How we support

Support covers upgrades of the self-hosted CMS, security patches and restore tests after go-live, under a retainer.
We can rerun the export from Storyblok during a parallel run period if content is still being edited there.
Compliance evidence, such as access logs and backup records, is prepared for your auditors, who issue any formal assessment.