Migrating from Sanity to Payload.
We move teams off Sanity and onto Payload, pages, assets, URLs and search rankings intact. Tell us what you're running below and we'll scope the move.
A Sanity to Payload migration starts with a repeatable Content Lake export. The Sanity CLI writes a local tarball and includes assets by default, while the Export API streams non-deleted documents, including drafts and asset documents, as NDJSON. From there, Sanity document types are mapped into Payload collections and embedded schema objects become groups, arrays, blocks, or rich text fields according to how the content is used.
The work concentrates in three places: assets, references, and Portable Text. Assets move first into a Payload upload collection so image and file fields can resolve against new media IDs. Document references use Sanity `_ref` values, so entries are imported once with legacy IDs and updated in a second pass after every Payload document exists. Portable Text arrays are transformed into the exact Lexical shape produced by the project's Payload editor config, with styles, lists, decorators, annotations, inline objects, and custom blocks mapped explicitly. GROQ queries, Studio custom inputs, serializers, and application code are rebuilt because they do not come from the export.
Who runs the migration
We are a Payload partner agency and a top contributor to the project. When something in the platform needs attention, we have direct access to the maintainers.
We have run this kind of move at enterprise scale. We migrated Ingersoll Rand's China sites off Oracle Content Manager in five months, with zero downtime at cutover, and we built the Council of Europe Development Bank's events platform to the deadline of their 70-year anniversary.
The first conversation is a free consultation. Scope, cost, and timing are agreed before any work starts.