How do you migrate from Sitecore (XP or SitecoreAI) to Sanity?

How do Sitecore templates, items, renderings and placeholders map to Sanity?

Sitecore templates map to Sanity schema types, content items to documents, and each page's layout to an array field on a page document. Sitecore compares templates to classes and items to instances; a page's layout is renderings in placeholders, each fed by a datasource item (Sitecore, Content authoring concepts, October 2026). A Sanity page builder is an array of objects or references, with no pre-built blocks (Sanity Docs, Page building, October 2026).

How do you get content out of Sitecore?

The Authoring and Management GraphQL API (application programming interface) is the export route on SitecoreAI and on Sitecore Experience Platform (XP) 10.5. Sitecore documents it on both as one endpoint and schema with read/write access (Sitecore, SitecoreAI docs; Sitecore, XP 10.5 docs, October 2026). SitecoreAI is the new name for XM Cloud, Sitecore's cloud Experience Manager (XM) (Sitecore, October 2026). On an older XP release, confirm the route in that version's documentation first. Two other routes do narrower jobs:

• Sitecore Content Serialization writes items to YAML for structural items such as templates, renderings and placeholder settings (Sitecore, Content Serialization, October 2026). It mainly feeds your schema map; read structure from it, and take content through the GraphQL API.
• Experience Edge serves published content and a snapshot of the Layout Service output for a route (Sitecore, Experience Edge, October 2026). Call it per URL to record each page's layout; it's a delivery API, not a bulk export.

Export effective values, not stored ones. A Sitecore field left unset (NULL) shows its template's standard value, and Sitecore advises keeping layout settings there (Sitecore, Standard values, October 2026). Sanity initial values only fill new documents created in Sanity Studio (Sanity Docs, Initial Value Templates, October 2026), so an import that skips standard values lands with blank fields.

How does Sitecore Rich Text become Portable Text?

Sitecore Rich Text becomes Portable Text through htmlToBlocks() and custom deserializer rules, because the field stores HTML text, including internal links and images (Sitecore, The simple field types, October 2026). Sanity's Learn course converts rich text this way and turns internal links into references through a URL map (Sanity Learn, Convert rich text to Portable Text, October 2026). Sanity's migration skill for AI agents has no Sitecore guide, only ones for Adobe Experience Manager, Contentful, Strapi, Webflow, WordPress, Payload, Drupal and Markdown (Sanity on GitHub, October 2026), and Sanity calls it "agent-scaffolded, not fully automated" (Sanity August releases, October 2026). Write a rule for each pattern in your own HTML:

• Internal links: resolve each linked item to its Sanity document and store a reference, so links survive URL changes.
• Images: swap each media item for a Sanity image asset with its alt text.
• Tables: the Portable Text Editor edits tables from Studio v6.6.0; the feature is off by default and needs a table schema type you declare (Sanity Docs, Configure the Portable Text Editor; Sanity's August 2026 release notes, October 2026).
• Inline styles and wrapper markup: keep what editors need and drop the rest, because it's presentation.

Log every element no rule handles, since each one is a schema decision. How Portable Text stores rich text explains the target format.

What happens to the Sitecore Media Library, language versions and numbered versions?

Sitecore Media Library items become Sanity assets, language versions become localized documents or fields, and numbered versions mostly stay behind. Sitecore keeps two kinds of versions per item: numbered versions in one language, such as a promotion copy of a page, and language versions (Sitecore, Versioning, October 2026).

Sitecore keeps alt text on each language version of an image (Sitecore, Versioning, October 2026); in Sanity, put it on the image field of each language's document. Our review of Sanity's localization models helps you choose.

How do you import Sitecore items into Sanity?

Import Sitecore items as NDJSON (newline-delimited JSON) with sanity datasets import, and use each item's globally unique identifier (GUID) as its Sanity document ID, so a rerun with --replace overwrites the same documents instead of duplicating them (Sanity Docs, Datasets command reference, October 2026). Key each language version as the item GUID plus the language code, such as <guid>-en. Sanity accepts IDs made of letters, numbers, hyphens and underscores (Sanity Docs, Import data, October 2026), so strip any other characters; reused source IDs make the script idempotent (Sanity Learn, Migrating without downtime, October 2026).

Shared datasources can land in any order. References import as weak and flip to strong once every document is in place (Sanity Docs, Import data, October 2026), so a shared datasource document and the pages that use it need no set import sequence.

The rest of a safe import is the same for every source CMS (content management system): validation, a rehearsal, --missing for datasets editors already use, paused webhooks and rollback. Safe imports into Sanity covers them.

What happens to Sitecore URLs, redirects and SEO?

Every Sitecore URL needs a matching Sanity route or a permanent redirect to protect search engine optimization (SEO), aliases included. Sanity's re-platforming course says to crawl the live site as well as export its content, and that the new front end "should not create a new link structure without appropriate redirects" (Sanity Learn, re-platforming course, October 2026).

Sitecore aliases need their own entries in the URL map. An alias gives one content item more than one URL, and Sitecore warns that this "can confuse search engines" (Sitecore, Aliases, October 2026). So export every alias, give each item one canonical URL in Sanity, and redirect every alias to that URL instead of rebuilding aliases as extra routes (Deploi's judgment).

Where the redirects run, how many your host allows and the checks after launch work the same for every source CMS (content management system): keeping SEO through a move to Sanity covers them.

What replaces Sitecore's workflow, roles and modules?

Sitecore's workflow and modules don't migrate to Sanity: each is mapped to Sanity roles, rebuilt in a separate service, or dropped. Sitecore's own list of what SitecoreAI lacks names the marketing pieces, from xDB (Sitecore's Experience Database) personalization rules to EXM (Email Experience Manager) and Sitecore Forms (Sitecore, Limitations and restrictions, October 2026), so moving to SitecoreAI rebuilds them too. SitecoreAI keeps workflows in its Content Editor (Sitecore, SitecoreAI, October 2026).

How Sanity and Sitecore compare weighs the full marketing suite, and Sanity Workflows tracks its release.

What is the step-by-step plan for a Sitecore to Sanity migration?

A Sitecore to Sanity migration runs in seven steps, one site at a time, so each site's content model and redirects are proven before the next starts. Sanity's course advises starting with low-risk content (Sanity Learn, October 2026). Leaving Sitecore says whether your Sitecore version's support dates set the pace.