How do you migrate from Adobe Experience Manager to Sanity?

Why is an AEM to Sanity migration a remodel, not a copy?

An Adobe Experience Manager (AEM) to Sanity migration is a remodel because AEM builds pages from components, and its Text component edits rich text as HTML (Adobe, Text Component, October 2026). Sanity's re-platforming course says recreating your structure as-is "opens the door to recreating your existing problems, just on a new stack" (Sanity Learn, Planning a re-platforming project, October 2026). Sanity's own tools leave the scripting to you, as of October 2026:

• Sanity has no AEM course or importer; its migration skill for AI agents has an AEM guide (Sanity agent toolkit, October 2026) and is "agent-scaffolded, not fully automated" (Sanity August releases, October 2026).
• Sanity's WordPress course says many of its techniques "will be directly transferable" to AEM (Sanity Learn, WordPress migration introduction, October 2026).
• Sanity's MCP (Model Context Protocol) server lists guided paths from Contentful, WordPress, Strapi and Drupal only (Sanity blog, October 2026).
• Sanity says Tata Digital moved 20,000 documents out of AEM with a single script in under 17 hours (Sanity, Tata Digital, October 2026).

Whether to leave AEM is a separate call: Adobe's core support for AEM 6.5 on premises ends 28 February 2027 and extended support, critical fixes only, ends 28 February 2028 (Adobe, AEM 6.5 support timelines; Adobe, AEM 6.5 FAQ, October 2026), and the AEM 6.5 deadline decision weighs every exit.

How do AEM pages, templates and fragments map to Sanity?

Adobe Experience Manager (AEM) pages map to Sanity document types, and their components become objects in an array. Content Fragments are the easy part: each comes from a Content Fragment Model, a structured model built in AEM's model editor (Adobe, Introduction to Headless for AEM, October 2026). Sanity's course says to use as few pages as possible and reference meaningful content documents instead (Sanity Learn, re-platforming course, October 2026), so Experience Fragments, AEM's reusable groups of components, become referenced documents.

How do AEM components and rich text become Portable Text?

Convert each Adobe Experience Manager (AEM) Text component to Portable Text, Sanity's structured rich text format, with htmlToBlocks() from @sanity/block-tools and custom deserializer rules. The Text component's Rich Text Editor edits HTML, and its Source Edit view shows "the raw HTML" (Adobe, Text Component, October 2026). The default converter handles paragraphs, headings, lists and inline formatting; "anything else needs an explicit deserializer rule" (Sanity Learn, Convert rich text to Portable Text, October 2026).

Tables need a decision up front. AEM's Rich Text Editor inserts tables, and the Portable Text Editor's built-in table editing, available from Studio v6.6.0, is disabled by default and binds to a table schema type you declare (Sanity Docs, Configure the Portable Text Editor, October 2026).

Every other component becomes an object type in a page builder, which Sanity describes as "an array of custom object or reference types that can be reordered" (Sanity Docs, page building guide, October 2026). Use objects for content that lives on one page and references for content reused across pages, such as Experience Fragments. Name types for meaning, such as a hero or a promotion, not for layout. Log every component type the converter skips, because each one is a schema decision. How Portable Text stores rich text explains the target format.

How do you get content and assets out of AEM?

Adobe's knowledge base lists the supported ways out of Adobe Experience Manager (AEM): append .model.json to a published page URL for its component JSON, export asset metadata as CSV (comma-separated values), download assets in bulk as zip packages, script exports through the Assets HTTP API (application programming interface), and build packages in Package Manager (Adobe, Export AEM assets and content, October 2026). Static HTML through .export.zip works on AEM 6.5 only.

• Custom components appear in .model.json only if they implement the exporter interface, so test every component type before you write the converter.
• Script the Assets HTTP API and confirm the output keeps the folder hierarchy, as Adobe's article advises.
• None of these routes gives Sanity-ready content. They give component JSON, files and repository packages to transform.

Content Fragments are also readable over AEM's GraphQL API (Adobe, Introduction to Headless for AEM, October 2026). Adobe's Content Transfer Tool moves content from one AEM instance to AEM as a Cloud Service (Adobe, Content Transfer Tool, October 2026), so it doesn't help here. Because .model.json reads live published pages, the import script can re-run against fresh content until cutover, which is the idempotent script Sanity's course recommends (Sanity Learn, Migrating without downtime, October 2026). AEM export routes in depth and moving AEM Assets go further.

How do you keep AEM URLs, vanity URLs and redirects?

Keep Adobe Experience Manager (AEM) URLs by crawling the live site, exporting every redirect and vanity URL, and storing each as a redirect document in Sanity that your front end serves. AEM defines "redirects, vanity URLs, and virtual hosts" through resource mapping (Adobe, Resource Mapping, October 2026), and its two kinds of rule move differently:

• Pattern mappings pair a regular expression with a replacement (Adobe, Resource Mapping, October 2026), so each needs rewriting in your front end's syntax.
• Vanity URLs "do not support regex patterns" (Adobe, Resource Mapping for AEM as a Cloud Service, October 2026), so each one moves as a one-to-one redirect.

Sanity's redirects guide says there's no "one size fits all" approach, because frameworks handle redirects differently (Sanity Docs, Managing redirects with Sanity, October 2026). Sanity's refactoring course adds the first step: crawl the existing site "to find every route that needs recreating" (Sanity Learn, refactoring course, October 2026).

Count vanity URLs and pattern mappings before you pick the redirect method, because the count against your host's redirect limit decides between a configuration file and middleware. Keeping search traffic through a migration covers those limits, the URL map and monitoring.

What replaces AEM workflows, Launches, Multi Site Manager and permissions?

Sanity has a counterpart for every Adobe Experience Manager (AEM) governance tool except live copies, but the matches for workflows, Launches and custom permissions are in early access or on Enterprise as of October 2026. AEM workflows automate steps "such as approval and sign-off" (Adobe, Administering Workflows); Launches hold future page versions you promote to the source (Adobe, Launches); Multi Site Manager syncs live copies with a source (Adobe, Multi Site Manager, October 2026).

What else do you replace when AEM goes?

Leaving Adobe Experience Manager (AEM) also retires its delivery tier, so plan four replacements before cutover:

• Publish and Dispatcher. Your front end and its CDN (content delivery network) serve pages. Adobe's own Edge Delivery Services "replaces AEM Publish / Dispatcher" (Adobe, Edge Delivery Services, October 2026), which shows where that layer sits.
• Adobe Target and Adobe Analytics. Their page hooks move into the new front end, in Deploi's judgment; the Adobe stack after AEM covers each one.
• Forms. Forms built as components need a form service or an API (application programming interface) route, in Deploi's judgment.
• AEM Assets. Images and files move to Sanity assets. Media Library, Sanity's app to "centrally store assets for use across multiple applications and datasets", is an Enterprise add-on (Sanity Docs, Media Library; Sanity pricing, October 2026).

Each replacement is a cost driver, alongside component count and redirect volume (Deploi's judgment).

What are the steps of an AEM to Sanity migration, and what goes wrong?

An Adobe Experience Manager (AEM) to Sanity migration runs in seven steps, and the import re-runs. A re-run of sanity datasets import fails on existing IDs unless you pass --replace or --missing (Sanity Docs, Import data, October 2026); choosing between them has its own guide.