AEM to Sanity Migration Guide for Enterprises

Alright, so you’re exploring a migration from Adobe Experience Manager to Sanity.

Great move! You’re probably here because AEM’s licensing fees are hard to justify, your developers are tired of the Java/Sling/OSGi complexity, or your editors are stuck waiting weeks for simple content updates. Whatever brought you here, you’re in the right place.

Now, we know what you’re thinking. This looks like a really comprehensive guide (and yes, it is—we covered everything).

But here’s the thing. Your time is precious, and we’re not going to make you read 10,000 words just to find the answer to one question.

So, we’ve made it easy for you.

Here’s a quick roadmap to help you navigate this guide and get straight to the answers you’re looking for:

• Start here if you want to discover the benefits of migrating to Sanity for your technical, editorial, and marketing teams.
• Start here if you want to address common objections people often have about AEM to Sanity migration.
• Start here for a DIY step-by-step guide on how to handle the migration yourself.
• Start here if you have specific questions about your unique migration needs.

Or skip all of that and book a free 30-minute call with us.

Let’s get into it and figure out how to get you from AEM to Sanity without the headaches!

Why You Should Migrate From AEM To Sanity?

If you are already convinced to migrate from AEM to Sanity, then skip ahead to the section — How to migrate.

However, if you want to explore a few reasons and benefits for migrating to Sanity from AEM, read on.

The Benefits of Migrating from AEM to Sanity

Migrating from AEM to Sanity can offer significant advantages for various teams in your organization. Here’s a closer look:

Cost Comparison: AEM vs Sanity

One of the most compelling reasons enterprises migrate from AEM to Sanity is the dramatic difference in total cost of ownership.

AEM typically costs (varies by deployment model):

On top of those numbers, factor in specialized developer rates: $150–$250/hour for AEM/Java/Sling specialists—one of the most expensive talent pools in the CMS world, and one of the hardest to hire for.

Sanity’s transparent, usage-based pricing:

Estimated Sanity costs for enterprise:

• Growth plan for 30 users: $450/month ($5,400/year)
• Enterprise plan (typical): $80,000–$128,000/year (includes custom usage, dedicated support, SSO, custom roles, onboarding)
• Developer costs: 50–70% lower (JavaScript/TypeScript vs. specialized Java/Sling/HTL)
• Total 3-year cost: $200,000–$400,000

Cost savings comparison (3 years):

Most enterprises save 80–90% on total CMS costs within the first year of migrating from AEM to Sanity, with even greater savings compounding over time.

Note: Costs based on an enterprise with ~30 content editors, approximately 1 million monthly visitors, and moderate usage. Actual costs may vary based on specific requirements and usage patterns.

High-Level Comparison: AEM vs Sanity

Sanity’s modern architecture aligns perfectly with enterprises seeking content agility, lower total cost of ownership, and long-term maintainability.

Common Objections About AEM To Sanity Migration

We understand that migrating from an established CMS like AEM to a headless platform like Sanity raises questions. Let’s address the most common concerns we hear from enterprises considering this migration:

How To Migrate From AEM To Sanity

You’ve made the decision to move from AEM to Sanity—excellent choice! Now comes the exciting part where we turn that decision into a structured, efficient, and future-ready migration.

In this comprehensive guide, we’ll walk you through every stage of the process—from planning and content modeling to migration execution and post-launch optimization.

Migrating from a traditional CMS like AEM to a modern, headless platform like Sanity doesn’t have to be intimidating. With the right strategy, tools, and planning, you can ensure a smooth, secure, and scalable transition that maintains your content integrity, preserves SEO equity, and empowers your team with a more flexible content architecture.

Whether you’re a developer, content architect, or digital strategist, this guide provides actionable steps, technical insights, and best practices to help you confidently navigate the migration.

Let’s break down the process into manageable phases—starting with the foundation: strategy and planning.

Step 1: High-Level Strategy

Before diving into the technical aspects, let’s map out a strategic approach to ensure your migration from AEM to Sanity is successful. A well-planned migration strategy will save you time, resources, and potential rework down the line.

Migrating from AEM to Sanity isn’t simply moving content—it’s transitioning from a legacy, monolithic, Java-based CMS to a modern composable content platform that enables flexibility, scalability, and speed.

1.1 When Should You Migrate?

Timing plays a crucial role in an enterprise CMS migration. The right time to move isn’t just when your developers are ready—it’s when your business, content operations, and technology roadmap are aligned.

Here are clear signals it’s time to consider migrating from AEM to Sanity:

• AEM contract or license renewal approaching: If your AEM as a Cloud Service contract or AEM Sites license is up for renewal in the next 3–6 months, it’s the perfect time to evaluate Sanity’s license-free, usage-based pricing before locking into another expensive multi-year cycle.
• Rising maintenance costs: AEM requires highly specialized developers and Adobe Managed Services support. Sanity’s schema-driven model and open ecosystem significantly reduce long-term maintenance overhead.
• Java/AEM talent shortage: Hiring AEM developers is increasingly difficult and expensive. Migrating to Sanity opens up your hiring pool to the much larger JavaScript/TypeScript developer community.
• End-of-support for your AEM version: If you’re on AEM 6.4 or earlier (already past extended support) or AEM 6.5 (extended support ending), instead of upgrading to AEMaaCS (which is essentially a re-platform anyway), consider migrating to Sanity—a platform that evolves continuously via API-first updates.
• Slow publishing workflows: If your editors often wait on developer involvement for simple updates (component tweaks, dialog changes, layout adjustments), Sanity’s real-time collaboration and structured content editing will streamline that process.
• Scalability and performance limitations: As your digital ecosystem grows, AEM’s scaling costs rise steeply (more publish instances, dispatcher tuning, replication agents). Sanity’s Content Lake and CDN-backed APIs scale instantly and globally without performance degradation.
• Technical debt accumulation: Over years of AEM customization—custom components, OSGi configurations, workflow models, dispatcher rules—many organizations build rigid, hard-to-maintain systems. Migrating to Sanity offers a clean, modern foundation built for headless architecture.
• Re-platforming to AEMaaCS anyway: If Adobe is pushing you toward AEM as a Cloud Service (which requires significant refactoring of existing AEM 6.x implementations), the cost and effort of moving to Sanity is often comparable—but you get a fundamentally better platform.

Pro tip: Enterprise-grade migrations typically take several weeks to months depending on your content volume, data complexity, and custom features. Begin planning 3–6 months before critical deadlines to ensure enough time for data modeling, testing, and training.

When to Stay vs When to Migrate

1.2 Why Migrate to Sanity?

If you’re reading this guide, you’re already considering Sanity—and for good reason. Sanity has rapidly become one of the leading headless CMS solutions used by organizations like Figma, Nike, Cloudflare, and National Geographic.

Here’s why Sanity stands out as the ideal alternative to AEM:

• Composable and API-first: Sanity lets you structure and deliver content exactly how your frontend applications need it—perfect for omnichannel publishing without AEM’s page-bound rendering model.
• Cost-effective and scalable: No costly licensing fees or server overheads. You only pay for what you use, and scaling is automatic—no more provisioning publish instances or dispatcher tuning.
• Schema-driven architecture: Content models live in code—version-controlled, flexible, and developer-friendly. No more managing component dialogs, content policies, and template configurations across multiple JCR paths.
• Real-time collaboration: Multiple editors can work on the same document simultaneously with real-time updates and version tracking. No more author instance locking conflicts.
• Custom workflows: Build editorial workflows tailored to your team using Sanity Studio’s extensibility—simpler than configuring AEM Workflow Models in Java.
• Developer ecosystem: Sanity integrates seamlessly with modern frameworks (Next.js, Remix, Astro, etc.) and offers SDKs and APIs that simplify frontend connections.

Want to see Sanity in action? Watch this quick 2-minute overview of how Sanity’s Content Operating System works:

Here’s a high-level comparison between AEM and Sanity:

Sanity’s modern architecture aligns perfectly with enterprises seeking content agility, lower total cost of ownership, and long-term maintainability.

1.3 Same Design or New Design?

When migrating from AEM to Sanity, you have two main design approaches:

If your existing design is strong and aligns with your brand, you can migrate your content models and replicate the frontend in a modern framework (e.g., Next.js, Remix). But if your brand or UX needs modernization, migration is a great opportunity to refresh.

• Keep Existing Design: Suitable when the current design is modern, time and budget constraints exist, and minimal disruption is needed.
• Opt for New Design: Recommended when the design is outdated, usability issues arise, or significant brand evolution occurs.

Consider a hybrid approach—maintain your core brand identity while rethinking component structures for Sanity’s modular and reusable design model. This maximizes both efficiency and scalability.

This is also a great opportunity to escape AEM’s component-bound design constraints. Many AEM sites end up with rigid layouts because designers have to work within the limits of available components and templates. Sanity’s composable approach lets designers and content teams work without those constraints.

1.4 Which AEM Features Should You Keep?

Migrating to Sanity doesn’t mean losing your favorite AEM capabilities. In fact, Sanity provides streamlined, developer-friendly equivalents for most features—often with more flexibility and less complexity.

1.5 Define Your Migration Objectives

Before moving forward, clearly define why you’re migrating and what success looks like:

Common migration objectives:

• Reduce costs by eliminating AEM licensing fees and infrastructure overhead
• Improve editorial efficiency with modern, collaborative tools
• Enable omnichannel content delivery across web, mobile, and IoT
• Increase development velocity with modern JavaScript frameworks
• Enhance performance through API-driven architecture
• Future-proof your content infrastructure
• Escape Adobe ecosystem lock-in and gain best-of-breed flexibility

How will success be measured?

• Content parity between AEM and Sanity
• SEO rankings maintained or improved
• Editorial team productivity gains (time to publish)
• Developer velocity improvements (time to implement features)
• Cost savings realized within the first year
• Site performance metrics (Core Web Vitals)
• Reduction in content-related support tickets

1.6 Choose Your Migration Approach

You have three primary approaches for migrating from AEM to Sanity:

• Full Migration (Big Bang): Move all content at once. Best for smaller sites needing urgent AEM exit. Fastest but higher risk.
• Phased Migration (Gradual): Migrate sections incrementally with testing between phases. Best for large, complex AEM sites with many sub-sites or properties. Lower risk, longer timeline.
• Hybrid Approach (Parallel): Run both systems simultaneously during transition. Best for mission-critical sites requiring zero downtime. Most complex but safest.

Our recommendation: For most enterprises—especially those with multi-site AEM deployments using MSM—a phased migration offers the best balance of risk management and efficiency. Migrate one site or property at a time, validate, then move to the next.

1.7 Who Should Handle the Migration?

Deciding whether to handle your AEM to Sanity migration in-house or hire experts depends on several factors:

Consider Your Internal Team If:

• You have JavaScript/TypeScript developers available
• Your team has experience with headless CMS platforms
• Your AEM implementation is relatively straightforward (limited custom components, no heavy MSM usage)
• You have 4–6 months for the migration
• You’re willing to accept learning curve risks

Hire Migration Experts If:

• Your AEM implementation is highly customized (complex Sling Models, custom workflows, OSGi configs)
• You have multiple sites managed via MSM with complex Live Copy inheritance
• You need to minimize timeline and risk
• You lack headless CMS experience
• You want knowledge transfer to your team
• You need post-launch support and optimization

The Hybrid Approach:

Many successful migrations employ a hybrid approach where:

• Migration experts handle technical architecture and content transfer
• Your internal team contributes domain knowledge and requirements
• Post-migration, your team takes ownership with initial expert support

This collaboration leverages outside expertise while building internal capabilities, setting you up for long-term Sanity success.

What to look for in a migration partner:

• Proven track record of AEM to Sanity (or similar headless) migrations
• Experience with modern JavaScript frameworks (Next.js, Remix, etc.)
• Strong case studies from similar industries
• Understanding of JCR, Sling, and AEM component architecture (so they know what they’re unwinding)
• Transparent methodology and migration process
• Commitment to knowledge transfer and training
• Post-launch support offerings

At Multidots, we bring extensive experience with complex CMS migrations and specialize in helping enterprises transition to modern, headless architectures. We’ve helped organizations migrate from AEM, Sitecore, Drupal, and other traditional platforms to flexible, scalable solutions.

As certified Sanity experts, we combine deep technical knowledge with proven migration methodologies to ensure your transition is smooth and successful.You can also book a free 30-minute call with us for any questions on Sanity.

Step 2: Getting Ready For The Migration

With a high-level migration strategy in place, you’re ready to tackle the necessary preparations to ensure a smooth process. This preparation phase is critical—it prevents data loss, maintains SEO equity, and ensures all stakeholders are aligned.

2.1 Backup Strategy

First things first—always, always back up your data. This is your safety net should anything go wrong during migration.

Here’s how to create comprehensive backups of your AEM environment:

Content backup:

• Log into AEM as an administrator
• Navigate to Tools → Deployment → Packages (or open Package Manager directly at /crx/packagemgr/)
• Use Package Manager to create packages of your /content tree
• Build packages for each major site or content area separately (avoid one giant package)
• Download .zip packages and store in multiple secure locations

DAM (Digital Asset Management) backup:

• Navigate to Package Manager
• Create a package targeting /content/dam (filter by your specific DAM paths)
• For very large DAMs, split into multiple packages by folder
• Download all media assets with metadata intact
• Document asset relationships and usage across content

Configuration backup:

• Export all AEM templates and editable templates (/conf/<your-project>/settings/wcm/templates)
• Export content policies (/conf/<your-project>/settings/wcm/policies)
• Document custom components and their dialogs (/apps/<your-project>/components)
• Save OSGi configurations (/apps/<your-project>/config*)
• Record user roles, groups, and permissions
• Export workflow models and launchers
• Back up dispatcher configuration files

Code repository backup:

• Ensure your AEM codebase (Maven multi-module project) is fully committed to Git
• Tag the current production version
• Document any environment-specific configurations not in source control

Database/repository backup:

• For on-premise/AMS: Create full backups of the JCR repository (use crx2oak or filesystem-level backup of the segment store)
• Include Lucene index backups for faster restore
• For AEMaaCS: Use the built-in Cloud Manager backup capabilities
• Test restore procedures in a development environment before proceeding

Pro tip: Test your backups by restoring them to a development environment before proceeding with migration. Store backups in multiple locations, including secure cloud storage with encryption enabled. AEM repositories can be massive (often 100GB+), so plan your storage accordingly.

2.2 Content Inventory and Audit

A thorough content inventory helps you understand exactly what needs to be migrated and how it should be organized in Sanity.

What to inventory:

Content types and volumes:

• Total number of pages by template type
• Content Fragments and Content Fragment Models
• Experience Fragments and their variants
• Media assets in DAM (images, videos, PDFs, documents)
• User-generated content (if applicable)
• Archived or unpublished content

Content relationships:

• How content is interconnected (component references, fragment references, links)
• Tag taxonomies (cq:Tag namespaces and structures)
• Content hierarchies and navigation structures
• MSM Live Copy relationships and rollout configurations
• Language Copy relationships and inheritance chains
• Related content associations

Custom functionality:

• Custom components and their dialog configurations
• Sling Models and their backing logic
• Personalization rules (Adobe Target activities, ContextHub configurations)
• Forms (AEM Forms or custom) and their submission data
• Custom workflows and approval processes
• Integration points with external systems

Content quality assessment:

• Identify outdated content for archival
• Find duplicate or redundant content (common in AEM sites with heavy MSM usage)
• Note content requiring updates or rewrites
• Flag content with broken links or missing assets
• Identify orphaned Content Fragments not referenced anywhere

Use tools like Screaming Frog or Sitebulb to crawl your AEM site and generate comprehensive reports. For internal AEM auditing, use AEM’s built-in Reports console or query the JCR directly with QueryBuilder for deeper analysis.

Pro tip: This is an excellent opportunity to clean up your content. AEM sites that have been around for years often have hundreds of orphaned Content Fragments, unused Experience Fragments, and abandoned MSM rollouts. Don’t migrate content you no longer need—it just adds complexity and cost.

2.3 Snapshot of Page Rankings & Performance

Before migrating, capture your current SEO and performance metrics. This gives you a baseline to compare against after migration and helps you prioritize high-value pages.

Tools to capture your pre-migration data:

• Google Search Console: Export all indexed URLs and their performance data
• Google Analytics: Pull organic traffic data for the past 6–12 months
• SEMrush/Ahrefs: Export keyword rankings for your top pages
• Screaming Frog: Crawl to capture all meta titles, descriptions, headers, and /content/ URL structures
• Google PageSpeed Insights/GTmetrix: Test key landing pages and record LCP, FID/INP, and CLS scores

Most importantly, export a complete list of your top-performing pages by organic traffic. These pages will need special attention during migration to preserve their SEO value—especially since AEM URLs typically include /content/<site>/ paths and .html extensions that you’ll likely want to clean up in the new structure.

2.4 Analyze AEM Content Structure

Understanding how your content is organized in AEM is crucial for planning its Sanity structure.

Document your content tree hierarchy under /content and how content is nested. List all AEM templates (both static and editable), their structure components, content policies, and any template inheritance. Catalog all components, their resource types, Sling Models, and HTL scripts. Map your tag taxonomies under /content/cq:tags including namespaces and tag hierarchies.

Document your MSM blueprints, Live Copies, and rollout configurations—this is often the trickiest part of an AEM migration to unwind. Pay special attention to:

• Live Copy inheritance chains: Which sites inherit from which blueprints
• Rollout configurations: Which fields are inherited vs. canceled
• Language Copies: How translations are organized
• Reference content: Content Fragments and Experience Fragments referenced across sites

This analysis ensures your Sanity schema maintains logical organization while leveraging Sanity’s more intuitive and flexible content modeling approach. Most AEM teams discover that Sanity’s structured content model can replace MSM with significantly less complexity—often using a single schema with site references instead of duplicated content trees.

2.5 Document Integrations and Dependencies

Your AEM site doesn’t exist in isolation—it’s part of a broader technology ecosystem. Documenting these connections ensures business continuity.

What tools to document:

• Adobe Experience Cloud (Target, Analytics, Campaign, Audience Manager)
• Marketing tools (HubSpot, Marketo, Eloqua)
• Ecommerce systems (Magento, Hybris, payment gateways)
• CRM platforms (Salesforce, Dynamics)
• Authentication providers (SSO, OAuth, IMS)
• Digital asset management (third-party DAMs if integrated)
• Translation management systems (TMS) connectors
• Search platforms (Adobe Search & Promote, Coveo, Algolia)
• Forms and submissions handlers (AEM Forms, Marketo Forms)

For each integration, document:

• How it connects to AEM (Sling Servlet, OSGi service, Cloud Service config, webhook)
• Data flows (what data moves where)
• Frequency of sync or updates
• Business criticality (must-have vs. nice-to-have)
• Whether you want to keep, replace, or remove it post-migration

Most integrations can be migrated or replicated with Sanity, often with simpler, more maintainable implementations using webhooks, serverless functions, or the API directly—no more wrestling with OSGi service registrations or Sling event handlers.

Step 3: Set Up Sanity

After mapping out your migration strategy, it’s time to establish your Sanity environment. This step is crucial as it lays the foundation for how your content will be structured, who can access it, and how users will interact with it.

A properly configured Sanity setup ensures that you’re not just replicating your AEM website, but actually enhancing it by leveraging Sanity’s flexibility, performance, and user-friendly features.

3.1 Install and Initialize Sanity

Let’s get your Sanity project up and running.

Installation steps:

1. Install Sanity CLI:

npm install -g @sanity/cli

2. Create a new Sanity project:

sanity init

You’ll be prompted to:

• Log in with your Sanity account (or create one)
• Choose a project name
• Select a dataset configuration (production, staging, development)
• Choose a starting template or blank schema

Start Sanity Studio locally:

cd my-sanity-project

sanity start

Your Sanity Studio will be available at http://localhost:3333

Pro tip: Start with a blank schema rather than a template. This gives you complete control over your content model from the beginning—especially important when you’re translating from AEM’s component-based model.

3.2 Content Modeling and Schema Design

Content modeling is where Sanity truly shines. Unlike AEM’s rigid component and template system, Sanity’s schema-driven approach gives you complete flexibility.

Best practices for schema design:

Start with document types:

Think of documents as your primary content types (Pages, Articles, Authors, Products, etc.).

// Example: Article schema
export default {
  name: 'article',
  title: 'Article',
  type: 'document',
  fields: [
    {
      name: 'title',
      title: 'Title',
      type: 'string',
      validation: Rule => Rule.required()
    },
    {
      name: 'slug',
      title: 'Slug',
      type: 'slug',
      options: {
        source: 'title',
        maxLength: 96
      }
    },
    {
      name: 'author',
      title: 'Author',
      type: 'reference',
      to: [{type: 'author'}]
    },
    {
      name: 'publishedAt',
      title: 'Published at',
      type: 'datetime'
    },
    {
      name: 'body',
      title: 'Body',
      type: 'blockContent'
    }
  ]
}

Map AEM concepts to Sanity schemas:

Use structured content (Portable Text):

Sanity’s Portable Text is a rich text format that’s portable across platforms—unlike AEM’s HTL-rendered HTML output, which is tightly bound to your AEM rendering layer.

{
  name: 'body',
  title: 'Body',
  type: 'array',
  of: [
    {
      type: 'block',
      marks: {
        annotations: [
          {
            name: 'link',
            type: 'object',
            fields: [
              {
                name: 'href',
                type: 'url'
              }
            ]
          }
        ]
      }
    },
    {
      type: 'image',
      options: {hotspot: true}
    }
  ]
}

Implement content references:

Sanity’s reference fields create relationships between documents—similar to AEM’s Content Fragment references and tag taxonomies but more flexible and bidirectional.

{
  name: 'relatedArticles',
  title: 'Related Articles',
  type: 'array',
  of: [{type: 'reference', to: [{type: 'article'}]}]
}

Create reusable objects:

For content blocks that appear across multiple document types (this is your Experience Fragment equivalent):

export default {
  name: 'seoMetadata',
  title: 'SEO Metadata',
  type: 'object',
  fields: [
    {name: 'metaTitle', type: 'string'},
    {name: 'metaDescription', type: 'text'},
    {name: 'openGraphImage', type: 'image'}
  ]
}

Replacing Experience Fragments:

In AEM, Experience Fragments let you reuse content across pages and channels. In Sanity, achieve the same with a combination of:

• Reusable object types for content blocks rendered inline
• Singleton documents for site-wide content (headers, footers, banners)
• Reference fields to pull shared content into multiple documents

This approach is more flexible than Experience Fragments because the same content automatically updates everywhere it’s referenced—no rollout configuration needed.

3.3 Set Up User Roles and Permissions

Sanity provides role-based access control (RBAC) to manage who can do what in your project.

Default roles:

• Administrator: Full access to project settings, datasets, and Studio
• Editor: Can create, edit, and publish content
• Viewer: Read-only access to content

Custom roles:

For more granular control, create custom roles in your Sanity project settings:

// Example: Custom role for "Contributor"
{
  name: 'contributor',
  title: 'Contributor',
  permissions: [
    {
      action: 'create',
      documentTypes: ['article', 'author']
    },
    {
      action: 'update',
      documentTypes: ['article'],
      filter: '_id in path("drafts.**")'  // Can only edit drafts
    }
  ]
}

This replaces AEM’s user/group/permission model (which is configured through useradmin or CRX/DE). Sanity’s RBAC is simpler and easier to audit—no more hunting through rep:policy nodes to figure out why someone can’t edit a page.

Pro tip: Start with broad permissions and narrow them down based on actual usage patterns. It’s easier to restrict later than to troubleshoot permission issues early on.

3.4 Configure Environments and Datasets

Sanity supports multiple datasets for different environments (production, staging, development). Think of this as a simpler replacement for AEM’s separate author/publish/dev/stage/prod environments.

Dataset configuration:

Create datasets for each environment:

sanity dataset create staging

sanity dataset create development

Set up Cross-Origin Resource Sharing (CORS) origins:

Configure which domains can access your Sanity content:

• Go to your project settings at sanity.io/manage
• Navigate to API settings
• Add CORS origins for your frontend applications:
  • http://localhost:3000 (development)
  • https://staging.yoursite.com (staging)
  • https://www.yoursite.com (production)

Configure API tokens:

Generate tokens for different purposes:

• Read tokens for public content delivery
• Write tokens for migration scripts and integrations
• Deploy tokens for CI/CD pipelines

3.5 Integrate with Your Frontend

Sanity is framework-agnostic, but here are the most common setups for replacing AEM’s HTL-based rendering:

Next.js Integration (Most Popular)

Install dependencies:

npm install next-sanity @portabletext/react @sanity/image-url

Create Sanity client:

// lib/sanity.js
import {createClient} from 'next-sanity'

export const client = createClient({
  projectId: 'your-project-id',
  dataset: 'production',
  apiVersion: '2025-01-01',
  useCdn: true,
})

Fetch content:

import {client} from '../lib/sanity'

export async function getStaticProps() {
  const articles = await client.fetch(`
    *[_type == "article"] | order(publishedAt desc) {
      title,
      slug,
      author->{name},
      publishedAt
    }
  `)

  return {
    props: {articles}
  }
}

GROQ (Sanity’s query language) replaces AEM’s QueryBuilder API. It’s more expressive, handles references and projections naturally, and runs at the edge—no more configuring search indexes or worrying about query performance under load.

Enable Preview Mode

Sanity’s real-time preview lets editors see changes before publishing—replacing AEM’s preview environment workflow:

1. Set up preview in Next.js:

// pages/api/preview.js
export default function preview(req, res) {
  res.setPreviewData({})
  res.redirect(req.query.slug)
}

2. Configure in Sanity Studio:

// sanity.config.js
import {defineConfig} from 'sanity'

export default defineConfig({
  // ... other config
  plugins: [
    // Add preview plugin
    previewPlugin({
      previewUrl: 'https://yoursite.com/api/preview'
    })
  ]
})

3.6 Implement Internationalization (if needed)

For multilingual sites, Sanity offers flexible i18n options that are far simpler than AEM’s Language Copy + MSM model.

Option 1: Document-level translations

Create separate documents for each language (similar to AEM’s Language Copies, but without MSM rollout complexity):

{
  name: 'article',
  title: 'Article',
  fields: [
    {
      name: 'language',
      type: 'string',
      options: {
        list: [
          {title: 'English', value: 'en'},
          {title: 'Spanish', value: 'es'},
          {title: 'French', value: 'fr'}
        ]
      }
    },
    // ... other fields
  ]
}

Option 2: Field-level translations

Use Sanity’s internationalization plugin:

npm install @sanity/language-filter

{
  name: 'title',
  type: 'object',
  fields: [
    {name: 'en', type: 'string'},
    {name: 'es', type: 'string'},
    {name: 'fr', type: 'string'}
  ]
}

Pro tip: Choose your i18n approach based on how much content varies between languages. If translations are straightforward word-for-word, use field-level. If content structures differ significantly by language, use document-level. For teams migrating from AEM Language Copies, document-level often feels more familiar and maps cleanly from existing structures.

Step 4: Launch

Now comes the exciting part—actually migrating your content and launching your new Sanity-powered site. This phase requires careful coordination and thorough testing to ensure everything works perfectly.

4.1 Content Migration from AEM

Content migration is the heart of your AEM to Sanity transition. Let’s break this down into manageable steps.

Export Content from AEM

You have several options for exporting content from AEM, depending on your version and content types:

Option A: Package Manager Export (works for all AEM versions)

• Step 1: Log in to AEM as an administrator
• Step 2: Navigate to Tools → Deployment → Packages (or /crx/packagemgr/)
• Step 3: Create a new package and define filters for your content paths (e.g., /content/your-site)
• Step 4: Build the package and download the resulting .zip file
• Step 5: Extract the package—you’ll find content as XML files (.content.xml) and binary assets

Option B: Content Fragment / GraphQL Export (AEMaaCS and AEM 6.5+)

For sites using Content Fragments, the AEM GraphQL API provides cleaner JSON output:

query {
  articleList {
    items {
      _path
      title
      author
      body {
        json
      }
    }
  }
}

This is significantly cleaner than parsing JCR XML and is recommended where available.

Option C: Assets HTTP API

For Content Fragments and DAM assets:

curl -u admin:admin \

 http://localhost:4502/api/assets/content-fragments/article-one.json

Option D: Custom JCR Query Export

For complex queries across the repository, use AEM’s QueryBuilder API or write a custom Sling Servlet that exports content as JSON:

http://localhost:4502/bin/querybuilder.json?path=/content/your-site&type=cq:Page&p.limit=-1

Step 1: Export additional languages

Repeat the process for each language variant if your site is multilingual—Language Copies typically live under /content/your-site/<lang>/.

Step 2: Store export files securely

Save the exported files in a secure location for transformation.

Transform AEM Content to Sanity Format

AEM exports content as XML (Package Manager) or JSON (GraphQL/HTTP API), which needs to be transformed into Sanity-compatible NDJSON. This typically requires custom scripts.

Example transformation script structure:

const fs = require('fs');
const xml2js = require('xml2js');
const sanityClient = require('@sanity/client');

const client = sanityClient({
  projectId: 'your-project-id',
  dataset: 'production',
  token: 'your-write-token',
  useCdn: false
});

// Read AEM content export
fs.readFile('aem-export.json', (err, data) => {
  const aemContent = JSON.parse(data);

  // Transform AEM structure to Sanity format
  const sanityDocuments = transformToSanity(aemContent);

  // Upload to Sanity
  sanityDocuments.forEach(doc => {
    client.createOrReplace(doc);
  });
});

function transformToSanity(aemData) {
  // Map AEM Content Fragment fields to Sanity schema fields
  // Resolve sling:resourceType to Sanity document type
  // Handle Content Fragment and Experience Fragment references
  // Convert HTL/rich text to Portable Text
  // Map cq:tags to Sanity references
  // Resolve DAM asset paths to Sanity asset references
  // Return array of Sanity documents
}

Common transformation challenges with AEM content:

• JCR property naming: AEM uses jcr: and cq: prefixes that don’t translate directly—strip and map these to Sanity field names
• HTL/rich text to Portable Text: AEM stores rich text as HTML in text properties. Use a parser like @portabletext/block-tools to convert HTML to Portable Text blocks
• Component nesting: AEM components nest inside par (paragraph system) or container components. Flatten these into Sanity arrays of content blocks
• Reference resolution: AEM references (fragmentPath, fileReference, etc.) point to JCR paths. You’ll need to resolve these to Sanity document _ref values after all documents are imported
• Multifield to array: AEM multifields export as numbered child nodes (item0, item1, etc.)—convert these to proper Sanity arrays

Pro tip: Start with a small subset of content (10–20 items) to refine your transformation scripts before migrating everything. AEM content often has edge cases that only surface at scale, so test your script on diverse content types early.

Verify Content Migration

After importing, verify that the content appears correctly:

1. Check document counts in Sanity Studio match AEM page/fragment counts
2. Validate field mappings – titles, slugs, rich text, dates, references
3. Verify references between documents (authors, categories, related content, fragment references)
4. Test rich content rendering with Portable Text (especially content that was complex HTL)
5. Confirm media assets are linked correctly (DAM paths resolved to Sanity assets)
6. Review localized content if multilingual (Language Copies properly grouped)

Use Sanity’s Vision plugin to run GROQ queries and inspect your dataset—it’s the Sanity equivalent of AEM’s CRX/DE Lite for repository inspection.

4.2 Migrate Media Assets

Media assets are crucial for user experience and SEO. Here’s how to migrate them from AEM’s DAM to Sanity.

Export Media from AEM DAM

Step 1: Navigate to Assets in AEM (/assets.html/content/dam)

Step 2: Use Package Manager to export DAM content

Create packages targeting /content/dam or specific DAM folders. For large DAMs, split into multiple packages by folder structure.

Step 3: Download media packages

Store them in an organized folder structure that mirrors your DAM hierarchy.

Alternative: For AEMaaCS or large DAMs, use the Assets HTTP API to programmatically download assets:

curl -u admin:admin \

 http://localhost:4502/content/dam/path/to/asset.jpg.assetdownload

This works better for automation and handles renditions correctly.

Optimize Assets for Sanity

Before importing, optimize your assets:

Images:

• Compress without quality loss (use tools like ImageOptim or TinyPNG)
• Convert to modern formats (WebP) where appropriate
• Strip unnecessary AEM-generated renditions (you only need originals—Sanity generates renditions on-the-fly)
• Ensure proper naming conventions
• Add descriptive alt text (extract from AEM metadata where possible)

Videos:

• Compress for web delivery
• Consider hosting on specialized platforms (YouTube, Vimeo, Mux) and referencing in Sanity
• For self-hosted, ensure proper codec and bitrate

Documents:

• Compress PDFs
• Ensure accessibility (searchable text, proper structure)
• Consider converting very large files to optimized versions

Pro tip: Sanity automatically handles image optimization and CDN delivery. Your images will be served through Sanity’s CDN with on-the-fly transformations. This eliminates the dispatcher caching headaches and asset rendition management you dealt with in AEM. You typically don’t need to migrate AEM’s auto-generated renditions—just the original assets.

Bulk upload to Sanity:

Use the Sanity client to bulk upload assets and update references:

const fs = require('fs');
const path = require('path');

async function uploadAsset(filePath) {
  const asset = await client.assets.upload('image', fs.createReadStream(filePath), {
    filename: path.basename(filePath)
  });
  return asset._id;
}

4.3 URL Mapping and SEO Preservation

Maintaining SEO equity during migration is crucial. Proper URL mapping ensures you don’t lose search rankings—and AEM migrations have a unique advantage here because you typically clean up bloated /content/ paths in the process.

Create Comprehensive URL Map

Export all AEM URLs:

Use a crawler like Screaming Frog to export all current URLs:

• Public pages
• Blog posts and articles
• Media assets (especially PDFs indexed in search)
• Any other indexed content

You can also export from AEM directly using the sitemap (/content/your-site/sitemap.xml) or by querying for all cq:Page nodes.

Map to new Sanity-powered URLs:

Create a spreadsheet mapping old AEM URLs to new URLs. AEM URLs typically need significant cleanup:

SEO improvement opportunity: AEM URLs typically include /content/<site-name>/<lang>/ prefixes and .html extensions that bloat URLs and dilute SEO value. Migrating to Sanity is the perfect time to clean these up. Just make sure every old URL has a 301 redirect to the new clean URL—missing even a few important redirects can cost you rankings.

Implement redirects at the edge:

For Next.js + Vercel deployments, configure redirects in next.config.js or vercel.json. For Cloudflare or similar, use redirect rules. Avoid implementing redirects at the application layer if possible—edge redirects are faster and don’t consume your serverless function budget.

4.4 Testing Your New Website

Thorough testing is critical before taking your new Sanity-powered website live. Here’s what you should test and how to do it effectively.

Start by validating all content in Sanity Studio—check that documents, field mappings, references, and media assets migrated correctly.

Test your frontend functionality including dynamic routes, real-time preview, and interactive components across multiple browsers and devices using tools like BrowserStack. Run performance audits with Google Lighthouse and GTmetrix to ensure you meet Core Web Vitals benchmarks. AEM sites often have heavy initial loads due to the clientlib system—you should see substantial improvements here on the new architecture.

Validate all SEO metadata, 301 redirects, and sitemaps to preserve search rankings. Pay particular attention to redirects from old /content/ URLs—missing redirects here are the most common cause of post-migration ranking drops. Finally, test third-party integrations, webhooks, and any automated workflows to ensure everything functions seamlessly before launch.

Step 5: Train Your Team

Congratulations! Your AEM content has successfully migrated to Sanity, and your new headless CMS is up and running. But the migration doesn’t end here.

Your team, accustomed to AEM’s Touch UI authoring, content fragment editor, and component-based page composition, now faces a completely new digital workspace—Sanity Studio—which operates differently from traditional CMS platforms.

Proper training ensures your team feels confident, productive, and empowered to leverage the full capabilities of Sanity.

5.1 Learn Sanity Basics

Sanity is designed for flexible, structured content management, but there’s still a learning curve—especially coming from AEM’s page-based, component-driven model. Tailoring training to your team’s roles ensures efficiency and smooth adoption.

Suggested Learning Paths:

Beginner Users (Editors & Content Creators):

• Navigating Sanity Studio dashboard (vs. AEM Touch UI)
• Creating, editing, and publishing content
• Understanding document types, fields, and Portable Text blocks (vs. AEM’s HTL components)
• Working with images and media library (vs. AEM DAM)
• Using preview mode to see changes before publishing

Intermediate Users (Marketers & Power Editors):

• Using references and nested components (replacing Content Fragment / Experience Fragment workflows)
• Managing media assets and optimizing images
• Working with drafts, versions, and publishing workflows
• Scheduling content for future publication
• Understanding content relationships and how they replace MSM Live Copies

Advanced Users (Administrators & Developers):

• Configuring and customizing schemas (vs. AEM template/component development)
• Managing datasets, roles, and permissions
• Leveraging webhooks and API queries (replacing AEM Workflows and Sling Servlets)
• Integrating with frontend applications (Next.js, Remix, etc.)
• GROQ query language (replacing AEM QueryBuilder)
• Troubleshooting common issues

See how content teams actually work in Sanity Studio with this comprehensive demo. This demo shows real-world workflows that your team will use daily after migrating from AEM.

5.2 Create Internal Training Materials

Task-specific guides help your team transition from AEM to Sanity effectively. Focus on creating practical resources tailored to your workflow.

Video Tutorials

Short, focused video tutorials are invaluable for learning complex actions in Sanity Studio:

• Adding and publishing a new document or page (vs. creating a page in AEM)
• Updating existing content without breaking structured fields
• Uploading and optimizing images using Sanity’s asset pipeline
• Managing references between documents (authors, categories, tags)
• Using Portable Text for rich content creation (vs. AEM’s RTE)
• Triggering frontend rebuilds via webhooks or preview updates (vs. AEM publish/dispatcher invalidation)

Pro tip: Screen recordings with clear narration are effective—professional production is not required. Host these videos in a central location (Google Drive, Notion, or your intranet) accessible to the entire team.

Quick Reference Guides

Provide one-page cheat sheets or PDF guides for recurring workflows:

• Editorial workflow checklists (draft → review → publish)
• Best practices for using Portable Text and rich content blocks
• Media asset standards (file types, resolution, alt text)
• Decision trees for content classification and tagging
• Common troubleshooting tips
• AEM-to-Sanity terminology glossary (so your team can mentally bridge the gap)

These quick references help editors and marketers work confidently without constantly searching for help.

Internal Documentation

Create a central knowledge base for your team:

• Schema field descriptions and when to use each
• Content guidelines and brand standards
• SEO best practices for your organization
• Workflow diagrams showing approval processes
• Migration mapping reference (what content from AEM lives where in Sanity)
• Contact information for support and escalation

5.3 Professional Training from Sanity Experts

While self-guided learning is helpful, professional training ensures your team fully grasps the differences between AEM and Sanity, minimizing frustration and accelerating adoption.

At Multidots, we are certified Sanity experts with extensive experience implementing and migrating to Sanity CMS. When you choose Multidots for your AEM to Sanity migration, comprehensive team training is included as part of our migration services.

Our Training Includes:

Custom workshops tailored to your specific Sanity project and content architecture

Role-based sessions designed for editors, administrators, marketers, and developers

Hands-on exercises using your actual dataset and frontend setup—not generic examples

Advanced feature sessions:

• Mastering Portable Text for flexible, structured content
• Content modeling best practices for your use cases (especially translating AEM patterns)
• Working with references and relationships effectively (replacing Content Fragments and MSM)
• Leveraging webhooks, integrations, and API queries

Live Q&A sessions addressing your team’s specific questions and scenarios

Follow-up support during the critical first 30–60 days post-launch to ensure smooth adoption

Benefits of Professional Training:

Ready To Migrate From AEM To Sanity?

At Multidots, we’ve helped enterprises migrate off legacy CMS platforms—including AEM, Sitecore, Drupal, and others—into modern, headless architectures. As certified Sanity experts, we bring the technical depth to unwind complex AEM implementations (Sling Models, MSM rollouts, Content Fragments, Experience Fragments, custom workflows) and the migration discipline to keep your SEO equity, content integrity, and editorial team intact through the transition.

Here’s what you can do next:

• Book a free 30-minute migration call. Walk us through your AEM setup. We’ll give you an honest read on timeline, complexity, and whether Sanity is actually the right fit. No sales pitch, no pressure.
• Get a free AEM-to-Sanity migration assessment. We’ll audit your current AEM environment, identify the trickiest parts of your migration (custom components, MSM dependencies, integration points), and send you a tailored migration plan with a realistic estimate.

Most enterprises we talk to spend 6–12 months thinking about migrating off AEM before they actually start. That’s 6–12 more months of license fees, infra costs, and slow publishing cycles. If you’ve already decided AEM isn’t the future for your business, the best move is to start the conversation now. Book your free migration call.