Migrate from Sanity to Strapi

Migrate from Sanity to Strapi: what the move involves

The move is mainly a data and modelling exercise, and it is usually carried out by a platform or back-end engineer working with a content lead who knows the editorial model. The schema work is the part editors notice, but the export, reload and verification of documents and assets is where most of the effort sits. Sanity Studio is MIT licensed, but the content itself lives in Content Lake, Sanity's hosted real-time data store, so Studio code alone does not move anything. You need to export the dataset with the Sanity CLI, which produces a gzipped tarball of documents, history and assets, and then load that content into your own Strapi database.

Strapi 5 runs on PostgreSQL, MySQL, MariaDB or SQLite, and it does not support MongoDB or other NoSQL databases, so confirm your database choice before modelling anything. Map each Sanity document type to a Strapi collection type or single type, then translate references into Strapi relations and convert Portable Text into the rich text format your Strapi fields will store. Assets in the export are skipped when Sanity returns 401, 403 or 404, so list those gaps early and agree with the content owners how to recover them. Ask whether published and draft states must both survive, since Strapi's content history and releases are features whose availability depends on your edition.

The effort is moderate and carries mainly data-quality risk: broken references, lost drafts, unmapped portable text blocks and missing media. Plan a dry run on a copy of the dataset, keep the Sanity dataset read-only until editors sign off, and confirm which Strapi features your editors need, such as SSO or audit logs, because those sit in the separately licensed Enterprise Edition. Scope and timeline depend on the size of the dataset and the number of document types, so ask for them to be estimated against your own export rather than taken from a general figure.

Which Sanity capabilities map to Strapi and which need rework

This table compares the Sanity capabilities your content depends on with their nearest Strapi equivalents. Read each row as clean (true), needs rework (null) or gap (false), and check the plan column before you commit to features that sit in Growth or Enterprise.

Sanity capability	Strapi equivalent	Status
Document types in Studio code	Content types built in the admin GUI or as JSON schema files in the project	Not applicable
References between documents	Relations (one-to-one, one-to-many, many-to-many) between content types, rebuilt as fields	Not applicable
Portable Text rich text	Rich text (Markdown or blocks) or a custom field, so Portable Text blocks need a converter	Not applicable
Assets in Sanity Content Lake	Media Library, re-uploaded from the export tarball with asset references rewritten	Not applicable
Drafts and published versions	Draft and publish is built in, but full content history and releases start at the Growth plan	Not applicable
Real-time collaborative editing	Not offered as Sanity offers it, so editors work with locking and standard saves	No
Roles and editor permissions	Roles and permissions in the admin panel, which you map again by hand	Not applicable
Audit logs and review workflows	Enterprise Edition features under a separate Strapi license, not in Community	No
Admin login through single sign-on	SSO covers administrator login only, with an add-on on Growth and inclusion in Enterprise	Not applicable
End-user authentication for the site	Users and Permissions plugin, configured separately from admin SSO	Not applicable

How to rebuild Sanity schemas as Strapi content types

Decide the target content model before you load a single document, because Strapi does not translate Sanity's schema files for you. In Sanity, document types, object types and references are defined in code inside Sanity Studio. In Strapi, the equivalent work happens in the content-type builder, where editors and developers can model collections, single types and components directly in the admin panel. Map each Sanity document type that has its own lifecycle and list page to a Strapi collection type, and map singleton documents such as site settings to a single type. Sanity object types, which are nested field groups reused inside documents, usually become Strapi components. Sanity references become Strapi relations, and you should record for each one whether it is one-to-one, one-to-many or many-to-many, because Strapi's relation fields set that cardinality explicitly. Write this mapping as a table in your project wiki and have the editors who will use the model sign off on it.

Plan the database before the import, since Strapi 5 does not support MongoDB or other NoSQL databases. The export from Sanity is a set of NDJSON documents, and the data will land in PostgreSQL, MySQL, MariaDB or SQLite, which your team operates and backs up. Check the supported database and Node.js versions in Strapi's installation documentation before you pick hosting, and confirm them against the version you intend to run. Choose the database engine, the backup schedule and the restore test as decisions owned by your platform team, because Strapi stores content types, components and relations as tables and generated schema files that must match the data you load. A useful early check is to build the content types in a non-production instance, load a sample of documents, and confirm that the relations and components resolve before you commit to the full migration.

Which exports and integrations to move from Sanity

Moving to Strapi is less a data copy than a set of separate jobs: pulling the dataset out of Content Lake, recreating the wiring that editors and front ends depend on, and re-establishing access. Each card below is one of those jobs, with the check that tells you it is finished.

Dataset export and skipped assets

The sanity dataset export command writes a local gzipped tarball that includes document history and asset files. It skips any asset that returns a 401, 403 or 404 response, so a clean export does not prove every image and file arrived. Log every skipped asset, decide whether each one is still referenced by a published document, and re-source it from its original location before you import into Strapi. Ask whether your dataset uses private or restricted assets, since those are the most likely to be skipped.

Document history and drafts

The export carries document history, but Strapi does not replay Sanity's revision log. Decide which history matters to editors, usually the current published version and any drafts still in progress, and export only those into Strapi's draft and publish model. Confirm with editors which unpublished drafts they need before cutover, because a draft that is not carried over is lost from the editing workflow.

Webhooks and build triggers

Sanity webhooks typically notify static site builds, search indexers or cache purges when content changes. Strapi needs its own webhooks configured for the same events, pointing to the same consumers. Inventory every Sanity webhook, record its trigger and target, and test each one against a Strapi staging instance before you switch the editing environment.

GROQ queries to REST or GraphQL

Every GROQ query in your front end must be rewritten as a Strapi REST or GraphQL request. Strapi 5 changes the API response format and replaces the Entity Service API with the Document Service API, so queries written against a v4 response shape need review. Use the Strapi-Response-Format: v4 header only as a temporary bridge while you update the consuming code, and check that populate and filter behavior returns the same nested data your templates expect.

Preview configuration

Editors who preview unpublished content in Sanity need the same experience in Strapi. Preview links, draft tokens and the front-end routes that render drafts must be rebuilt against Strapi's draft and publish model. Test preview for each content type that editors use, including nested components, and confirm that preview never exposes draft content on public URLs.

Users, roles and permissions

Sanity project members, their roles and their dataset access do not move with the content. Recreate administrator accounts and role assignments in Strapi by hand, and map each Sanity role to a Strapi role with explicit permissions per content type. If you need single sign-on for the admin panel, confirm which edition includes it, since SSO is an add-on on the Growth plan and included in Enterprise, and it covers administrator login only.

How the migration changes by starting point

A single dataset with a modest number of document types is the simplest starting point. The export is one tarball, the schema work is a short list of content types, and the editorial team usually needs only a few days of practice in the Strapi admin panel before they can work confidently. The main decisions are about how much history to keep and whether your frontend reads from Sanity's GROQ queries or from a generic API.

Schema rewrite: Each Sanity document type becomes a Strapi content type. Keep the list short and avoid copying every field if some were only used for layout.
History: Decide whether past document revisions matter. Most small sites only need the published state, which reduces import work.
Frontend changes: Replace GROQ calls with Strapi REST or GraphQL requests and check every page template against the new response shape.
Assets: Re-upload images from the export so Strapi stores them under its own media library, then check alt text and crops.
Hosting: One Strapi instance and one database are usually enough, so the recurring work is mainly upgrades and backups.

Before starting, confirm with your team that the export is complete and that no pages depend on Sanity-only features that Strapi does not reproduce.

Migration sequence from inventory to decommission

This sequence moves a Sanity dataset into a self-hosted Strapi project in controlled stages, so each content type is proven before editors and frontends switch. Every stage closes with a named artifact, and Sanity is retired only after a retained export has been verified and archived.

Inventory schemas, content and integrations
The platform owner and a lead developer list every Sanity document type, object type, reference, Portable Text field and image or file field in the Studio schema code. They count documents per type from the dataset, note draft and published states, and record every consumer of the Content Lake, including frontends, GROQ queries, webhooks, image transforms and scheduled publishing. The output is an inventory sheet that maps each type to a planned Strapi content type, component or relation, with an owner for each open question. The step is done when editors and developers have both signed off the sheet.
Build a pilot content type in Strapi
A developer creates one representative content type in a self-hosted Strapi 5 project, chosen because it uses references, rich text and images. The project runs on a supported database, such as PostgreSQL, as listed in Strapi's installation requirements. The developer writes a import script that reads a local copy of the Sanity export, converts documents, resolves references and uploads assets. The output is a tested import script and a short set of test documents that editors can review in the Strapi admin panel.
Load the full dataset and reconcile
The team exports the full Sanity dataset with the sanity dataset export command and keeps the resulting tarball as the source of truth. The import script runs against a staging Strapi instance for every content type in the inventory. A reconciliation report compares document counts, reference integrity, locale coverage, asset counts and a sample of rendered Portable Text against the export, and lists every skipped or failed record. Assets that the export skipped because of 401, 403 or 404 responses are logged by ID and assigned to an owner for manual recovery.
Run a parallel period with Sanity read-only
Editors and frontend developers work in Strapi on staging while Sanity is set to read-only as the authoritative source, so no edits are split across two systems. The team tests frontend queries against the Strapi REST or GraphQL APIs, checks draft and publish behavior, and confirms that scheduled content and webhooks behave as expected. Each defect found is traced back to the inventory sheet or import script and fixed there, then the reconciliation report is rerun. The period ends when the open defect list is empty and the editorial team accepts the staging content.
Cut over editors and frontends
The team writes a cutover runbook that lists the final export and import order, the freeze window for editing in Sanity, the DNS or deployment changes for each frontend, the rollback path and the named person who approves each step. The final Sanity export is taken after editing stops, imported into production Strapi, and reconciled again before frontends are pointed to the new API. The runbook is considered complete when a dry run has been performed on staging and the rollback has been tested.
Retain the export and decommission Sanity
After the frontends have run on Strapi for a period the owner agrees in writing, the team archives the final Sanity dataset export and the Studio schema code in storage they control, with checksums and a record of where it is kept. They confirm that the archive can be read without Sanity by opening the NDJSON documents and asset files. Only then are the Sanity project, datasets, tokens and webhooks disabled, and the access list is revoked. Ask your Sanity contract manager for any export or retention terms that apply to your plan before you disable the project.

Running Sanity and Strapi in parallel before cutover

Keep Sanity as the only editing source until Strapi has passed its own tests, then move editors in a single, short window. While Strapi is built, the Sanity dataset stays live and editors keep publishing there. Your team loads a full export into a Strapi staging instance on a regular schedule, so each rebuild of the content types, mapping scripts and asset import runs against recent content rather than a snapshot from months earlier. Record the dataset name, export date and Studio schema version for every load, so a failed test can be traced back to the exact input.

Reconcile counts and references before anyone trusts the staging instance. Compare the number of documents per document type in the export with the number of entries per content type in Strapi, and treat any gap as a defect until it is explained. Then check references: every relation that pointed at another document in Sanity should resolve to a matching Strapi relation, and every asset that the export skipped on a 401, 403 or 404 response should appear on a list you can hand to the content owners. Run the same checks against the staging database engine you plan to use in production. Strapi 5 requires PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later or SQLite 3, and an Active or Maintenance LTS Node.js version. Confirm these versions with Strapi's installation requirements before you build the test environment, so that query behavior, migrations and the runtime match what production will run.

Plan the freeze as a short, rehearsed sequence. Announce a cutoff, switch Studio users to read-only access through your own process (confirm with Sanity how project roles and dataset permissions are changed for your plan), run a final export, load only the delta into Strapi, repeat the count and reference checks, then point the front end at Strapi. Rehearse this whole sequence at least once on staging and time it, so the freeze window reflects measured work rather than an estimate. Decide in advance who can stop the cutover if the delta check fails, and keep the Sanity dataset untouched until the Strapi site has been verified, because it remains your rollback path.

What drives the cost and duration of the Strapi migration

This table lists the main factors that change the effort and recurring spend of moving a Sanity dataset into Strapi. Read each row for who is paid, whether the cost is one-time or recurring, and what you can do to keep it down. The main takeaway is that schema work and Portable Text conversion usually dominate, while Strapi plan fees are only one recurring line among hosting and database costs.

Driver	Why it changes cost or effort	How to keep it down
Schema count and nesting	Each Sanity document type and object type becomes a Strapi content type or component, and deep nesting adds mapping and testing work.	Inventory types first, consolidate duplicates, and flatten nesting where editors do not need it.
Portable Text complexity	Custom marks, annotations and embedded blocks need converters to Strapi rich text or blocks, and each custom block needs its own rendering check.	Limit custom block types, and list every one in the export before quoting conversion work.
Asset volume and missing assets	Large libraries take longer to download and re-upload, and the export skips assets returning 401, 403 or 404, which then need manual recovery.	Audit asset references before export, remove unused files, and ask who holds the source files.
Number of locales	Each locale multiplies entries and needs Strapi i18n configuration, translated field checks and editorial review.	Migrate the default locale first, then add others in later waves.
Integrations and webhooks	Sanity webhooks, GROQ-based front-end queries, and build triggers must be rewritten against Strapi's REST or GraphQL APIs.	Document every consumer of the Content Lake API before scoping.
Editorial training	Editors move from a code-defined Studio to Strapi's GUI content-type builder and admin panel, which requires training and workflow changes.	Run training on a staging copy, and reuse Strapi's own documentation for role setup.
Community versus Growth or Enterprise	Community Edition is free and includes REST and GraphQL APIs. Growth is listed at 45 US dollars per month including 3 users (Strapi self-hosted pricing page), and SSO, audit logs and review workflows sit in higher tiers.	Confirm which features you need, such as SSO or review workflows, before choosing a tier, and check current pricing with Strapi.
Hosting, database and upgrades	Your cloud provider, PostgreSQL service and engineering time recur, and Strapi 5 minor releases ship frequently, so upgrades recur too.	Ask for a quote that separates one-time migration work from monthly infrastructure and upgrade effort.

What Strapi Community and Enterprise editions include

Which Strapi features are free under the MIT Community Edition?

The core headless CMS is free under the MIT Expat license. Code outside the ee directories falls under that license, so the content types, the admin panel for ordinary editing, and the REST and GraphQL APIs are available without a license fee. The self-hosted pricing page lists the Community plan as free with unlimited users, and it includes REST and GraphQL APIs and unlimited entries and API calls. Your engineers still pay for hosting, the database, backups, upgrades and support. Confirm the exact feature list against the current Strapi pricing page for self-hosted plans and the LICENSE file before you assume a feature is in Community.

What is in the ee directories under the Strapi Enterprise license?

Code in directories named ee sits under the Strapi Enterprise Edition license, not MIT. Using that code requires a signed agreement with Strapi or a Strapi Cloud subscription. Your legal team should read the Strapi LICENSE file and map each enterprise feature you plan to rely on to a path in the repository. Do not assume that a feature in the admin panel is open source because the surrounding project is. Ask Strapi in writing which features your intended deployment uses and under which license they are provided, and record the answer with the procurement file.

Is SSO for Strapi admin login an extra cost on the Growth plan?

On the self-hosted Growth plan, SSO is an add-on, while it is included in Enterprise. The Strapi SSO feature covers administrator login to the admin panel through an identity provider such as Microsoft Azure Active Directory, with auto-registration, a default role and an optional local login lock-out. It does not handle end-user authentication on your website, which belongs to the Users and Permissions plugin. Confirm the current add-on price on the self-hosted pricing page, and ask whether your identity provider setup needs any custom work on your side.

Which Strapi features require the Enterprise plan, such as audit logs?

Audit logs and review workflows are Enterprise features on the self-hosted plans. Content history and releases start at the Growth plan, so they are not an Enterprise-only feature. Editorial controls that matter to regulated teams, such as who approved a change and when, usually depend on audit logging, so confirm these with Strapi before you design your approval process around them. Map each control your compliance team needs to a named plan and a named feature, and keep that mapping with your readiness evidence.

What does Strapi Cloud hosting cost by plan?

Strapi Cloud is a managed alternative, not a self-hosted edition. The cloud pricing page lists Starter at 35 US dollars per month per project, Pro at 90 dollars and Business at 450 dollars, each with API request, storage and bandwidth allowances. Only Business lists a 99.9% uptime SLA. These figures come from the Strapi Cloud pricing page and may change, so check them on the day you request a quote. Compare them with the hosting, database, backup and operations work your team would otherwise carry, because that work is the main difference between the two paths.

How should we compare the Strapi license cost with running it ourselves?

Start with the license line, which is zero for Community and a published monthly figure for Growth, then add the components that recur every month. These include servers or containers, a supported database such as PostgreSQL, object storage for assets, backups, monitoring, and the engineering time for upgrades. Strapi 5 requires a supported Node.js version, so the runtime needs its own patch cycle. One-time costs include the migration itself and the schema rebuild. Ask any implementation partner for a fixed-scope written quote that separates these items, so you can see which costs fall away and which remain if you change plans.

Can our team confirm Strapi edition entitlements without vendor help?

Yes, your team can check entitlements with the public documents, but it should record the result. Read the current self-hosted pricing page, the Strapi LICENSE file and the SSO documentation, then list each feature your editors and security team need. Check those features against the ee directories in the version you plan to deploy, not an older branch. Because the plans and releases change often, repeat the check before signing and again before each major upgrade. If a feature remains unclear, ask Strapi in writing rather than relying on a sales conversation.

What usually goes wrong in a Sanity to Strapi move

Most failed Sanity to Strapi moves break at the seams: references that point to nothing, rich text that loses its structure, assets that never arrived, and frontends that expect the old response shape. Each card below names one failure and the check that prevents it.

Lost references after loading

Sanity documents point to each other by ID, and those IDs do not carry over as Strapi relation IDs. If the import script writes documents before their targets exist, relations come back empty or wrong without raising an error. Load content types first, then entries in dependency order, and keep a mapping table from Sanity _id values to Strapi document IDs. After each load, count relations per type against the export and sample a few entries from every collection in the admin panel.

Portable Text converted incorrectly

Portable Text is an array of typed blocks, and custom marks, inline objects and nested lists do not map one to one onto Strapi's rich text fields. A naive conversion usually flattens embedded objects or drops annotations such as links with custom attributes. Decide per block type whether it becomes rich text, a component or a media reference, then render a sample of converted pages against the originals before any frontend reads them.

Missing or unreachable assets

The Sanity dataset export skips assets that return 401, 403 or 404 responses, so some files can be absent from the tarball without an obvious failure. Image references in documents can also point to asset IDs that were never downloaded. Compare the asset manifest with the export, list every skipped file, and confirm that each re-upload to Strapi's media library succeeds and that the stored URLs resolve from the public web and the frontend.

Editors rebuilding workflows without roles

Sanity projects often rely on Studio access rules and document-level habits that editors never wrote down. In Strapi, administrator roles, content permissions and review workflows must be configured on purpose, and review workflows sit in the Enterprise Edition according to Strapi's self-hosted pricing page. Before cutover, document who creates, reviews and publishes each content type, then test each role with a real account so no editor finds they can publish or cannot save.

Strapi v5 response format breaking frontends

Strapi 5 changes the API response format compared with v4, so queries and components written against v4 can fail or render empty fields. The Strapi-Response-Format: v4 header exists for backward compatibility during migration, but it is a transition aid, not a permanent contract. Pin the frontend to a tested response shape, run contract tests against both the staging API and the production frontend, and remove the compatibility header only after every consumer passes.

Skipping the database backup before upgrades

Strapi's v4 to v5 upgrade runs data migration scripts on first start, and the docs say downgrading is not supported. A failed migration on a database with no backup leaves you with a broken schema and no rollback path. Take a full database backup and a copy of the uploads folder, restore it into a scratch environment, run the upgrade there first, and only then schedule the production run in a window your team can monitor.

Questions teams ask before migrating from Sanity to Strapi

How much effort does a Sanity to Strapi migration take?

The effort depends mostly on how many document types, references and rich text fields you have, and on how much history you need to keep. Each Sanity schema has to be rebuilt as a Strapi content type in the admin builder, then the export data has to be mapped into it. Teams with a small number of types and clean content usually face a much smaller job than teams with deep reference chains, custom Portable Text blocks or large asset libraries. Ask any partner to size the work by content type count, field count, reference depth, asset volume and front-end changes, and to state which of those items are inside the quoted scope.

How long does the migration take, and what sets the timeline?

No duration is fixed for this migration, so the timeline should come from a written scope and a content inventory rather than a generic estimate. The main drivers are the number of content types, the complexity of the mapping from Sanity documents to Strapi relations, the amount of Portable Text to convert, the asset re-upload plan and the number of editor review rounds. Schedule risk also comes from the front end, because Sanity queries (GROQ) and any Sanity-specific image handling must be rewritten against Strapi's REST or GraphQL responses. Confirm with the vendor whether the timeline includes a parallel run and cutover window.

What does the work need from editors and engineers?

Engineers own the schema rebuild, the data mapping scripts, the asset import and the front-end query changes. Editors own the content check, because they know which fields carry meaning and which legacy content is still live. Before cutover, editors should review a sample of each content type in the Strapi admin panel, confirm that references resolve and that rich text renders correctly, and sign off on which drafts and unpublished items move. Ask the vendor to name who on your side approves the content mapping and who signs off the editor workflow.

Can an internal team run the migration without an outside partner?

An internal team can run the migration if it has engineers comfortable with Node.js, a Strapi 5 project, a PostgreSQL or other supported SQL database, and a repeatable data import process. The Strapi team should also own the ongoing operations, such as keeping the Node.js runtime on an Active or Maintenance LTS version and taking database backups before upgrades. Teams that have not run a CMS migration before often pay for the learning curve in rework. A partner is most useful for scoping, mapping review and cutover planning, and internal staff should be trained to run the system afterward. Confirm which parts of the work your staff can take on before you ask for a quote.

Is the Strapi Community Edition enough for a Sanity replacement?

The Community Edition is MIT licensed and covers the core content modeling, REST and GraphQL APIs and unlimited entries and API calls on the self-hosted pricing page. It does not include the features that Strapi places in the Enterprise Edition, such as audit logs and review workflows. Single sign-on for the admin panel is an add-on on the Growth plan and included in Enterprise. Code under the ee directories falls under the separate Strapi Enterprise license, so check that your team does not depend on those directories without a signed agreement. Compare the Community feature set against your current Sanity workflow, especially real-time collaboration and review steps, before you decide.

What happens to Sanity history, drafts and assets during the move?

The Sanity dataset export is a gzipped tarball that includes document history and asset files, but it skips assets that return 401, 403 or 404 responses, so those files must be recovered or recorded as gaps. Strapi does not import Sanity's document history as-is, so you should decide whether to keep only the current published versions, keep drafts as separate entries or archive the history in the export for reference. Assets need to be downloaded from the tarball, checked and uploaded to Strapi's media library or your object storage, and their references in content must be rewritten. Ask the vendor how they will report skipped assets and how history will be retained.

Which parts of the Sanity setup need a manual rebuild?

Several parts of a Sanity setup do not move as data and need manual work. These usually include:

Studio schemas, which become Strapi content types built in the admin builder or in code
GROQ queries and custom Studio input components, which must be rewritten against Strapi's APIs
Portable Text customizations, which need conversion to Strapi's rich text format
Webhooks, roles and access rules, which must be recreated and tested

Confirm which of these are in scope before you agree on a fixed timeline, because they often add more work than the content itself.

How DeployOpen scopes and runs a Sanity to Strapi migration

DeployOpen runs a Sanity to Strapi migration as a fixed-scope engagement in which the scope, deliverables and timelines are agreed in writing before any work starts. The written scope usually follows the stages a migration of this kind moves through: planning, schema rebuild, data transforms, asset import, a parallel run, cutover and hardening. Planning is where the content inventory is taken from the export, including which document types, locales and asset folders are in use and which editors depend on which workflows. The schema rebuild turns Studio schemas into Strapi content types and components, and it is the stage where editors should review the new builder screens before any content moves. Each stage ends with a deliverable the client can accept or reject, which keeps scope changes visible instead of absorbed into the price. Clients should ask for the stage list, the acceptance criteria for each stage and the named owner on both sides before signing.

The data transform and asset import stages carry most of the technical risk, so the written scope should name them explicitly. Transform work covers references between documents, Portable Text conversion into the rich text format the Strapi content types will use, and re-uploading assets with their metadata, along with the skipped asset list from the export. The parallel run keeps Sanity and Strapi receiving content for a period so editors and front-end developers can compare outputs before cutover, and the scope should state how long that period lasts and who signs off. Cutover and hardening cover database backups before any Strapi version upgrade, since the Strapi v4 to v5 documentation advises backing up first because downgrading is not supported, along with role setup for administrators and editors. Ongoing support, upgrades and continuous testing are available as separate retainers, which many teams choose because Strapi releases arrive often and need regular review.

Migrate from Sanity to Strapi