Migrate from Strapi to Payload or Sanity
Strapi 4 stopped getting security fixes at the end of April 2026, and v5 is a breaking upgrade. If you are touching every content type anyway, move to Payload or Sanity, with your content moved by script and every URL kept.
Yegparian PLLC (opens in a new tab)Signs it is time to leave Strapi
Strapi made self-hosted headless CMS approachable. These are the moments teams tell us it stopped fitting.
You are still on Strapi 4
Version 4 reached end of life in April 2026. No more bug or security fixes, and every new vulnerability stays open on your server.
The v5 upgrade is a rewrite
Strapi 5 changes the API response format, introduces document IDs and breaks plugins. For many sites the upgrade costs close to a migration.
Plugins hold the upgrade back
Community plugins written for v4 may never be ported. One abandoned plugin can keep the whole CMS on an unsupported version.
The schema lives in the admin
Content types built in the admin panel drift between environments. Teams want the model typed, in Git and reviewed like the rest of the code.
Two apps to run and deploy
A separate Strapi server, database and media store next to your front end. Payload runs inside your Next.js app, and Sanity is hosted for you.
What happens to your Strapi setup
Pick what your Strapi project uses today. Each part maps to something built into Payload or Sanity, or turns out not to be needed.
- Collection typesPayload collections or Sanity documentsEvery content type and field is rebuilt as a typed schema in code, with entries moved by script from your Strapi database or API.
- Single typesPayload globals or Sanity singletonsHomepage, settings and navigation stay one-of-a-kind documents your editors can find in the same place.
- ComponentsField groups and objectsReusable components become field groups in Payload or object types in Sanity, shared across every schema that uses them.
- Dynamic zonesPage-builder blocksEach component allowed in a dynamic zone becomes a block editors compose pages from, in the same order as today.
- Media libraryPayload uploads or Sanity assetsFiles are re-uploaded with their alt text and captions, from local storage, S3 or Cloudinary, with image resizing built in.
- Users and permissionsAuth and access control in codeAdmin roles are recreated, and front-end users move to Payload’s built-in auth or the provider you choose. Password resets are scoped per project.
- Internationalization pluginBuilt-in localisationEach locale moves per field or per document, with its own URLs and hreflang on the site.
- Draft and publishDrafts and versionsDrafts, publishing and revision history are built into both Payload and Sanity, with scheduled publishing available.
- REST / GraphQL APIGenerated APIs and typed queriesPayload generates REST and GraphQL from your config and adds a typed Local API. Sanity gives you GROQ and GraphQL. Front-end queries are rewritten.
- Lifecycle hooks and controllersHooks and endpointsCustom logic moves to Payload hooks and endpoints, or to Sanity Functions and webhooks, usually with the same behaviour.
What changes when you leave Strapi
Payload and Sanity are where your team edits. Astro and Next.js decide how pages are built. We recommend a pair after the audit.
| Feature | Astro + Sanity | Next.js + Payload | Strapi |
|---|---|---|---|
| Ownership | |||
| Self-hosted and open source | Open-source Studio | ||
| Content model typed in code, in Git | JSON files from the admin | ||
| Runs inside your front-end app | |||
| No CMS server to patch | Patched with your app | ||
| Content | |||
| Build content types without code | |||
| Reusable blocks for page building | |||
| Live preview while editing | Strapi 5, plan-based | ||
| Real-time collaborative editing | Document locking | ||
| APIs | |||
| REST and GraphQL out of the box | GROQ and GraphQL | ||
| Typed queries without HTTP calls | Local API | ||
Sites we've already moved
Different stacks for different jobs: a law firm on Next.js and Payload, a residential launch and our own studio on Astro and Sanity.
Yegparian PLLC
WordPressNext.js + Payload
An Austin trial litigation firm. Practice areas, matters and insights are Payload collections, and every page is pre-rendered and served from the edge.
yegparianpllc.com (opens in a new tab)25 Cuba
WordPressAstro + Sanity
A new residential address in Canary Wharf. Apartments, amenities and galleries are edited in Sanity, and the site ships as static Astro pages.
25cuba.com (opens in a new tab)Celerart
WebflowAstro + Sanity
Our own studio site. Every one of the 164 old URLs was carried over or redirected, and all content is now edited in Sanity.
celerart.com (opens in a new tab)
How we move a Strapi site
Your Strapi site stays live until the new CMS is ready. Editors keep publishing until the final content sync.
Audit
Audit
We read your schemas, components and dynamic zones, list every plugin, hook and custom controller, and crawl the live site, so nothing is lost by accident.
Content model
Content model
Content types, components and dynamic zones become a typed schema in Payload or Sanity, shaped around how your team actually edits.
Content import
Content import
Entries, relations, locales and media move by script from the Strapi database or API. Rich text is converted and images re-uploaded.
Front end
Front end
We rewrite the queries in your existing front end, or rebuild it in Next.js or Astro with the same design or a refresh if one is due.
Final sync and launch
Final sync and launch
A last import picks up anything published during the project. URLs, metadata and sitemaps are compared before the switch.
Handover
Handover
Your team gets a walkthrough of the new editor. Then the Strapi server and its database can be shut down.
Questions about leaving Strapi
Sometimes that is the right call, and the audit will say so. But v5 changes the API format and breaks many plugins, so the front end and custom code change either way. If you are paying for that work, it is worth comparing with a move.
Payload suits teams that want the CMS inside their Next.js app, self-hosted, open source and typed end to end, which is the closest fit for most Strapi teams. Sanity suits teams that would rather not host a CMS at all and want real-time collaboration. The audit recommends one.
Each component becomes a field group or object type, and each dynamic zone becomes a list of blocks. Entries keep their block order and nested data, and we check a sample of every content type by eye.
Admin accounts are recreated with matching roles. Front-end users can move to Payload’s built-in auth or another provider; whether existing password hashes carry over depends on the target, so we scope it per project.
Yes. If your Next.js, Nuxt or Astro front end works, we rewrite its queries for the new CMS and leave the rest alone. If it also needs work, we rebuild it in the same project.
You do. The repository, database, hosting account and domain are in your name. If you would rather not manage it, we can host it for you, with no lock-in.
It depends on the number of content types, dynamic zones, plugins and custom endpoints. After the audit you get a fixed scope and timeline, and the Strapi site stays live until launch day.
