Migrate from Contentstack to Strapi

How to migrate from Contentstack to Strapi without losing content control

The move from Contentstack to Strapi is a content model rebuild plus a scripted data import, usually led by a platform or development team with editorial sign-off. Strapi does not read a Contentstack stack directly, so the work is to recreate content types, components and relations in Strapi, then move entries, assets and locales through an import script that you write and test. The effort and risk sit mostly in the schema translation and in the content that does not map cleanly, not in the export itself.

Before you scope the work, confirm what the Contentstack CLI export carries over in your version and what it leaves behind. Run the export against a copy or test stack, then check the output for content types, global fields, entries, assets, locales and environments. Roles, users, workflows and releases are the usual gaps, so plan to rebuild them by hand in Strapi and confirm which self-hosted features you need: review workflows and audit logs sit on Strapi's Enterprise plan, while content history and releases start at Growth. Ask Contentstack and Strapi to confirm current behavior for your stack, since import formats and plan entitlements change.

Keep control of the content during cutover by freezing the model, rehearsing the import on a staging Strapi instance and comparing record counts, asset references and locale fallbacks against the source. Keep a complete export as your rollback copy and treat the Strapi database backup as mandatory before any upgrade. Editors should sign off on a sample of migrated pages and the frontend should be switched to Strapi's REST or GraphQL endpoints only after that sign-off, so that the source remains available until the new system is verified.

Which Contentstack capabilities map cleanly to Strapi and which need rework

This table maps the Contentstack capabilities you will migrate to their Strapi equivalents and labels each as clean, needs rework or gap. Read the fit column first to plan effort, then check the notes for the plan tier or export step that affects each item. Most content models and delivery APIs carry over, while workflows, audit logs and admin SSO depend on your self-hosted plan.

Capability	Strapi equivalent	Fit	What to plan
Content types	Strapi content types with fields and relations	Clean	Flat models map directly. Check relation direction and draft behavior after import.
Global fields	Reusable components and shared schema definitions	Needs rework	Recreate each global field as a component and confirm how nested components are handled.
Entries and locales	Entries as documents with per-field localization	Needs rework	Enable locales before import and mark each localized field so translations load correctly.
Assets	Media library with uploaded files and metadata	Needs rework	Download binaries during export, then resolve name collisions and remap references in entries.
Publishing and scheduled publishing	Draft and publish states; scheduled publishing needs confirmation	Needs rework	Confirm scheduled publish support in your edition, or plan a job that publishes at set times.
Workflows	Review workflows, Enterprise feature in self-hosted plans	Gap	Growth plans do not include review workflows. Plan an approval step outside Strapi or budget for Enterprise.
Roles and permissions	Admin roles and content permissions configured in Strapi	Needs rework	Roles are not exported, so rebuild each role and test access for every editor group.
Webhooks	Webhooks configured in the Strapi admin panel	Needs rework	Re-register each endpoint and confirm payload format with the receiving systems.
REST and GraphQL delivery	REST and GraphQL APIs included in all self-hosted plans	Needs rework	Strapi 5 changes the response format, so update frontend queries and test each endpoint.

What data moves, what needs a script and which integrations to rebuild

Each item below moves by one of three routes: a documented export path, a custom script against the Contentstack API, or manual recreation in Strapi. Confirm the route for each item on a test stack before you estimate effort, because the export's module list and its gaps decide how much work is scripted. Ask the current CLI documentation which modules the export returns and which it omits, especially user accounts, roles and release history.

Entries and content types

Content types, global fields and entries form the core of the move. Confirm with the current Contentstack CLI which content model and entry versions the export returns, then map each content type to a Strapi collection type and each global field to a shared component. Modular blocks usually become repeatable components. Run the export on a copy of the stack and compare entry counts per content type before you write any import script. Check whether unpublished draft versions are included, since the export may return only the latest published entries.

Assets and their files

Asset metadata and the binary files behind it usually need separate handling. Confirm whether the export downloads the files or returns only metadata and URLs, and whether those URLs stay reachable after your contract ends. Duplicate file names can overwrite one another on import, so check for collisions first. Keep a mapping from old asset identifiers to new Strapi media IDs so entry references resolve. A script can upload files to the Strapi Media Library and then rewrite the references inside imported entries.

Locales and translations

Locale codes are easy to lose in a migration. Export the locale list first and confirm each code, its fallback chain and the default locale. Confirm how your Strapi version enables localization on each content type before you import anything. Translated entries linked to a master entry need the same relationship rebuilt in Strapi, and a script should verify that every locale variant lands on the correct document. Test one multilingual entry end to end before running the full import.

Users, roles and release history

Plan for manual recreation of editor accounts and role permissions until the export proves otherwise. If the export omits users, roles and releases, rebuild them in Strapi's admin panel and document each permission set before cutover. For administrator login, Strapi SSO through an identity provider is an add-on on Growth and included in Enterprise, and it covers admin accounts only. Audit logs and review workflows are Enterprise features, so decide early which approval steps you need. Check the Strapi self-hosted pricing against that list.

Webhooks and extensions

Webhooks and custom editor extensions rarely carry over as files. Export the webhook definitions to capture target URLs, triggers and headers, then rebuild each one as a Strapi webhook or as a call from your build pipeline. Contentstack extensions are custom editor interfaces that Strapi does not run, so each needs a replacement: a custom field, a plugin, or an external tool that editors open separately. Confirm the webhook list against the current export before you assume it is complete.

Frontend API consumers

Every site, app and service that calls the Contentstack Delivery API needs a new client. Inventory each consumer with its query patterns, including the content types, locales, references and preview modes it uses. Strapi exposes REST and GraphQL APIs, and both are included in every self-hosted plan, but response shapes and population rules differ, so each query must be rewritten and tested. Run old and new delivery paths side by side behind a flag, compare rendered output, and switch the CDN or DNS only after the comparison passes.

Which Strapi version and database to target for the new build

New builds should target Strapi 5, not Strapi v4. Strapi v4 reached end of life on April 30, 2026, and its final release, 4.26.2 of June 9, 2026, will receive no further updates. Choosing v4 for a build that will run for years means planning a second migration almost immediately, so the decision is settled before any content is imported. Strapi 5 minor releases have shipped roughly weekly, so the team should pin an exact version in package.json, track the Strapi GitHub releases page, and schedule upgrades as routine maintenance rather than projects.

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, so a Contentstack export cannot be loaded into a document store of the same shape. For most enterprise teams the practical choice is PostgreSQL, which has the widest operational tooling for backups and replication. Confirm the chosen engine and version against the current Strapi installation requirements before provisioning, and confirm which Node.js release your hosting image provides, because Strapi 5 runs only on Active or Maintenance LTS Node.js versions. Pinning Node.js to a supported LTS line is part of the same decision as the database.

The API layer changes as well. Strapi 5 replaces the Entity Service API with the Document Service API in server code, and it changes the REST response format. Any frontend built on the Contentstack Delivery API must be rewritten to read the new shape, including how entries, relations and locales are returned. During transition, the Strapi-Response-Format: v4 header can keep older response shapes available, which helps when a frontend is ported in stages. Treat that header as a bridge, not a permanent setting, and list every frontend consumer and its response assumptions before cutover, so the switch is tested against the Strapi 5 format rather than the compatibility layer.

The migration sequence from inventory to decommission

This sequence moves Contentstack content, assets, locales and access rules into a self-hosted Strapi project in controlled stages, with a checkpoint and written output at each step. It ends with decommissioning the Contentstack stack only after a verified export archive is kept.

Inventory the stack and its dependencies
Engineering and content leads list every content type, global field, locale, environment, asset folder, webhook, workflow and role in the Contentstack stack, and record which frontends and integrations call its APIs. Note that the CLI export does not carry users, roles or releases, so those are documented by hand from the Contentstack settings. Done when the team holds an inventory document that names every module, its owner and the consuming applications, and the editors have confirmed which content is still live.
Map schema to Strapi content types
A developer translates each Contentstack content type and global field into a Strapi collection type, single type or reusable component, and decides how references, modular blocks and locales will be modeled. Strapi 5 runs on PostgreSQL, MySQL, MariaDB or SQLite, so the team also confirms the database and Node.js versions it will standardize on. Done when a mapping document lists every source field, its target attribute and any field that needs a transformation, and the content lead has reviewed it.
Import a pilot content type and its assets
The team exports the stack with the Contentful-compatible CLI commands in module order, then imports one representative content type, a few linked entries and their assets into a local Strapi instance. Developers check that media files resolve, references point to the right documents and rich text renders correctly. Done when the import log shows no unresolved references for the pilot and an editor has compared pilot entries against the originals in Contentstack.
Run the full scripted import into staging
The import scripts are extended to cover every content type, locale and asset, then run against a staging Strapi instance that the team can rebuild from scratch. Each run writes a log of created, skipped and failed records. Done when the reconciliation report shows entry counts by content type and locale that match the export manifest, and every failed record has a documented cause and fix.
Recreate workflows, roles and editorial checks
Administrators rebuild editorial roles and permissions in Strapi, then configure any review or publishing steps the team still needs. Because workflow features such as review workflows and audit logs depend on the self-hosted plan, the team checks which features it needs against Strapi's pricing page before designing the process. Done when a test editor and a test reviewer can complete the same publish path that existed in Contentstack, and the editorial checklist is signed off by the content owner.
Run a parallel period with both systems serving content
Frontends are pointed at Strapi on a preview or staging URL while Contentstack remains the production source. Editors enter the same changes in both systems during the window, and the team compares rendered pages and API responses for drift. Done when the team has a list of discrepancies, each resolved or accepted, and the response format differences between Contentstack and Strapi 5 are handled in the frontend code.
Cut over editors and frontend API calls
On an agreed date, editors stop publishing in Contentstack and the frontends switch their API base URLs, tokens and query shapes to Strapi. A final delta export captures anything changed after the rehearsal import, and the team freezes Contentstack writes during that window. Done when production pages render from Strapi, a final reconciliation matches entry counts by locale, and the rollback path has been tested.
Archive the export and decommission Contentstack
Before the Contentstack stack is deleted, the team stores the complete export, asset files, manifests and logs in an archive it controls, and verifies that the archive can be read. Access to the archive is restricted and documented. Done when a verification record confirms the archive is complete and readable, the retention owner has approved it, and only then the stack is closed and the contract ends.

What drives the cost and duration of the Contentstack to Strapi move

This table lists the factors that move the effort of a Contentstack to Strapi migration and shows how to keep each one under control. Read each row as a lever: the size of the content model and its dependencies, the volume of assets and locales, and the Strapi plan you choose set most of the work and most of the recurring cost.

Driver	Why it changes cost or effort	How to keep it down
Content types and global fields	Each content type needs a Strapi schema, a mapping decision and frontend queries. Global fields that are reused across types must be turned into shared components once, or they get rebuilt many times.	Audit unused content types before export. Consolidate near-duplicate types and agree the target component list before any import script is written.
References and modular blocks	Deep reference chains and nested modular blocks force import order and relation rebuilding. Errors surface late when an entry points to a record that has not been imported yet.	Map reference depth on paper first. Import in dependency order and keep block nesting shallow where the editorial model allows it.
Assets and file volume	Asset count and total size drive transfer time, storage on the new host and the cost of backup copies. Name collisions in exported files need manual review.	Remove stale assets, check which files actually download, and agree a naming rule before import. Ask the vendor for the asset list in your export.
Locales	Each locale multiplies entries and translations to verify. Fallback rules and locale codes must match between the two systems.	Confirm which locales are live and which are drafts. Migrate only active locales in the first pass and add the rest later.
Environments and branches	Content that differs between environments or branches must be reconciled into one source of truth. Only the published or latest state is exported, so unpublished work can be lost.	Decide the authoritative environment early. Record any in-progress branch work and rebuild it deliberately rather than assuming the export holds it.
Workflows and roles	Contentstack roles, permissions and workflow stages are not carried by the export. Strapi workflows, review steps and roles must be designed and configured by hand, and the review features depend on the Strapi plan.	Document current approval steps and who holds each role. Simplify the workflow to the stages you really use before rebuilding it.
Custom extensions and integrations	Custom UI extensions, webhooks and third-party integrations need equivalent code or service changes in the new stack. Each one adds design, testing and security review.	Inventory every extension and webhook. Retire unused ones and confirm which need a replacement before the cutover date is set.
Frontends and API consumers	Each frontend or service that reads Contentstack must switch to Strapi's API format. Strapi 5 changes the response format, so queries and rendering logic need updates and regression testing.	Count consumers and prioritize one frontend for the first cutover. Use the Strapi response format header only as a short bridge, not as a permanent setting.
Strapi plan and identity setup	Self-hosted Strapi features such as SSO, audit logs, review workflows and content history depend on the plan. Adding these later means extra licensing and configuration work.	Decide which features are required before build starts. Ask Strapi for a written quote covering the self-hosted plan you need, and confirm whether any ee/ code is in scope.
Cost components	People (migration engineers, content modelers, QA and editorial time), hosting, the database, backups and the Strapi plan carry the cost. Hosting and backups recur, while schema design, scripting and testing are mostly one-time.	Ask each bidder to price these components separately: scope and deliverables in writing, backup retention, environments for staging and production, and any support retainer after go-live. No figures are stated here until a written quote is provided.

What usually goes wrong and how to prevent it

Most failed Contentstack to Strapi migrations break at the seams: assets, locales, references, parallel editing, workflows, caching and deletion. Each card names one risk and the check that catches it before cutover. Run them in order, because a missed asset or reference later becomes a broken page in production.

Assets lost to name collisions

Contentstack allows assets with identical file names in different folders, and a flat import into Strapi's media library can overwrite or rename them. Failed downloads during export also leave gaps that surface only when a page renders. Build a manifest that maps each Contentstack asset UID to its new Strapi file ID, and keep the original file name in metadata. Then compare counts of exported, downloaded and uploaded files before you accept the import.

Locale fallbacks that break on import

Contentstack fallback chains between locales do not carry over automatically, so an entry that is blank in French may render empty instead of falling back to English. Strapi 5 stores each locale as its own version of a document, which means missing translations need an explicit decision. Confirm the locale list and fallback order in your frontend, then test one page per locale with an untranslated field before import.

References pointing to unmigrated entries

Entries that reference other entries, assets or global fields will fail silently if the target was not imported first or if its ID changed. This is most likely in nested modular blocks and in content types that reference each other in a cycle. Import in dependency order, store a mapping of old UIDs to new Strapi document IDs, and run a script that reports every relation with no target.

Editors working in the old stack

During a parallel run, editors who keep publishing in Contentstack create entries that the one-time export never sees, and the Strapi copy drifts. Choose a cutover date, freeze content types and publishing in Contentstack for the final export, and tell editors which system is authoritative for each content type. Re-run the delta export only for entries changed after the freeze.

Workflow states with no Strapi equivalent

Contentstack workflow stages and multi-step approvals do not map one to one onto Strapi. Review workflows are an Enterprise feature in Strapi's self-hosted plans, and content history and releases start at the Growth plan, so a plan choice can remove a state editors rely on. Write down every workflow stage in use, confirm which plan provides each one, and decide whether to rebuild it with a custom approval field before the move.

Stale frontend cache after cutover

Once the frontend reads from Strapi, CDN and framework caches can keep serving Contentstack responses or old entry shapes, especially when response formats change. Strapi 5 changes the API response format, and the Strapi-Response-Format: v4 header is only a bridge during migration. Purge caches as part of the cutover runbook, and check that a sample of pages returns Strapi data before you redirect traffic.

Deleting the stack before verification

Once a Contentstack stack or its API keys are removed, recovering content from the vendor may not be an option you can count on. Keep a verified archive of the export, including JSON and downloaded assets, with checksums, and confirm you can read it without the old system. Ask Contentstack in writing what it retains after termination before you set any deletion date.

How the move differs for a small team, an enterprise stack and a frontend-led build

A single website with a handful of content types usually has a short export and a small mapping exercise. The CLI export is quick to run and the schema fits in one afternoon of review, so most of the effort moves to hosting and ownership. Because Strapi 5 runs on PostgreSQL, MySQL, MariaDB or SQLite and needs an Active or Maintenance LTS Node.js version, the team must decide where the database lives and who applies Node.js and Strapi updates.

Export scope: Confirm that the CLI export covers every content type, entry and asset you need, and note what it leaves behind, such as users and roles.
Schema work: Few models means you can rebuild components and relations by hand and skip scripted translation.
Hosting: Pick a single node with managed backups for the database and the uploads folder, and document the restore steps.
Upgrades: Strapi 5 minor releases ship frequently, so assign one named person to read release notes and schedule updates.
Editorial access: Community Edition covers roles for a small team, but check whether SSO or review workflows matter before you commit to a plan.

Before cutover, confirm who restores a backup and who gets paged when the admin panel or public API is down.

Questions buyers ask before moving from Contentstack to Strapi

How much does a migration from Contentstack to Strapi cost?

The cost depends on the scope of the stack, and no fixed figure applies to every project. Your bill has four main parts: the self-hosted Strapi edition and its plan (Community is free, while the Growth and Enterprise plans carry license fees), the infrastructure you run it on, the migration engineering, and the people who maintain it afterward. The biggest drivers are the number of content types and components, how many locales and assets you carry over, whether the frontend is rebuilt, and how many workflows and roles need recreating. Ask for a quote built from a written scope that lists each module, the Strapi features you need, and the hosting assumptions. Compare that against your current Contentstack plan, extra user fees and add-ons over the same period.

How long does it take to move content from Contentstack to Strapi?

The timeline is set by schema complexity and the amount of frontend work, not by the number of entries alone. Teams usually lose the most time mapping global fields and modular blocks into Strapi components and deciding how references and locales are handled. Other variables include whether you run a v4 or v5 Strapi version, how many environments need rebuilding, and how much editorial sign-off the content needs. Your fixed-scope agreement should state milestones and dates in writing before work starts, and any estimate you receive should be tied to the modules and deliverables listed in that scope.

What do our editors and developers need to contribute?

Editors need to review the content model in plain language, confirm which entries are live, and test the migrated entries in a staging environment before cutover. Developers need to own the frontend switch from Contentstack's delivery API to Strapi's REST or GraphQL endpoints, plus the hosting, database and deployment setup. Expect editors to be asked to validate sample content types and their relationships early, because mistakes there are cheaper to fix before import. Agree on who signs off each stage, and who holds the keys to the admin panel and database.

Can our internal team run the migration without outside help?

An internal team can do it if it has someone who knows Strapi 5 well, experience with the Contentstack CLI and its export limits, and time to test in staging. Gaps usually appear in the schema translation, the import scripts for entries and assets, and the authentication and permissions setup. Contentstack's export does not carry users, roles or releases, so those must be rebuilt by hand whoever does the work. Decide early which parts your team owns and which parts a partner will handle, then write that split into the scope.

Can Strapi run the same review workflows as Contentstack?

Strapi can support review and approval processes, but the exact setup depends on your plan. Per the Strapi pricing page, review workflows are an Enterprise feature in the self-hosted plans, while content history and releases start at the Growth plan. Before you commit, map each Contentstack workflow stage to the Strapi feature that covers it, and confirm the edition and plan that include it. Where a workflow cannot be reproduced exactly, the team should decide whether to accept a simpler process or to build an approval step around the platform.

Do users and roles carry over from Contentstack to Strapi?

No, they do not carry over automatically. The Contentstack CLI does not export roles or permissions, so you need to recreate editor roles, permissions and admin accounts in Strapi by hand. If your organization uses single sign-on for the admin panel, Strapi SSO applies to administrator login through an identity provider, with a default role assigned to new users, and it is tied to the self-hosted plan tier. End-user authentication is handled separately by the Users and Permissions plugin. Confirm this mapping with your identity team before cutover.

How do we keep Contentstack and Strapi in sync during the parallel run?

Keep Contentstack as the source of truth until cutover, then run a defined sync window. Re-export changed content and assets on a schedule, reimport them into staging, and compare entry counts and sample records against the source. Freeze schema changes during the final migration pass so the mapping stays valid. Your frontend can read from Strapi in staging while editors keep working in Contentstack. Agree on a cutover date, a rollback plan and who decides when the switch is final, and record those decisions in the written scope.

How DeployOpen scopes, runs and supports the Strapi migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted Strapi inside your own cloud account, data center or air-gapped network. Each Contentstack to Strapi migration starts from a written scope, so the export, schema mapping, import and frontend switch are agreed before any work begins.

How we scope

Inventory every Contentstack stack, content type, global field, locale, environment and asset library before agreeing a fixed scope.
Record which workflows, roles and webhooks must be rebuilt in Strapi, since the CLI export does not carry users or roles.
Confirm the target Strapi version, database, hosting region and whether SSO or review workflows need a paid self-hosted plan.

How we build

Run the Contentstack export in the module order your scope specifies, then map content types and global fields to Strapi content types and components.
Write import scripts for entries, assets and locales, and test each import against a staging Strapi instance before cutover.
Adapt the frontend to Strapi's REST or GraphQL APIs, and test published content and draft behavior against the agreed scope.

How we hand over

Deliver schema documentation, import runbooks, role and permission matrices and a record of which Contentstack data was not migrated.
Set up backups of the Strapi database and media storage, and document the restore steps your team will run.
Walk your editors and engineers through the Strapi admin panel and the API changes agreed in the scope.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Plan Strapi version upgrades with your team, including a database backup before any major version change.
Ask for the support scope, response expectations and upgrade responsibilities in writing as part of the quote.