Sitecore Migration: Step-by-Step Guide from XP to XM Cloud

Short answer. Moving from Sitecore XP to SitecoreAI (formerly XM Cloud) runs in five phases: assessment, architecture, build, parallel running and cutover. For a mid-sized enterprise estate, plan for 9 to 14 months; large multi-site estates can take longer than 18 months. Most of the effort goes into rebuilding renderings as Next.js components, reworking integrations and migrating content in several passes.

Updated October 2026. Sitecore launched SitecoreAI in November 2025 as the evolution of XM Cloud, so read "XM Cloud" in this guide as SitecoreAI. This update adds a timeline by phase, hidden gotchas, a 90-day plan and FAQs. To check your own migration path, start with our free Sitecore audit.

Sitecore migration from XP to XM Cloud is now the most common modernization path for enterprise organizations running Sitecore’s on-premise stack. Sitecore has made its strategic direction clear: XM Cloud is the future, and extended support for XP will not last indefinitely. Organizations that delay their Sitecore migration face increasing maintenance costs, shrinking talent pools familiar with the legacy architecture, and growing gaps between their capabilities and what the modern Sitecore ecosystem offers.

 

Why Migrate to XM Cloud?

XM Cloud delivers several architectural advantages over XP. It is a fully managed SaaS platform: no more infrastructure management, patching, or upgrade cycles. The headless architecture with Next.js support enables modern front-end development and edge-cached delivery. The Pages visual editor gives marketers drag-and-drop page building on top of headless content. Since November 2025, SitecoreAI brings content management, customer data, personalization and search into one platform, with an Agentic Studio of AI agents that includes migration tooling agents.

From a business perspective, organizations completing Sitecore migration to XM Cloud typically aim for lower infrastructure management effort, faster time-to-market for content changes, and improved developer recruitment (modern JavaScript developers prefer Next.js over legacy .NET MVC). At Sengo, our team, led by a two-time Sitecore MVP, has guided multiple enterprise clients through this transition. This guide captures the methodology we have refined across those engagements.

Pre-Migration Assessment

Every successful Sitecore migration starts with a thorough assessment of what you are migrating from. Skipping this step is the single biggest cause of budget overruns and missed deadlines in migration projects.

Content inventory. Document every content type, template, and rendering in your current Sitecore XP instance. Identify how many content items exist, how they are structured in the content tree, and which templates they use. Map out media library assets and their references. This inventory determines the scope of your content migration effort.

Customization audit. Catalog all custom code: pipelines, event handlers, custom fields, workflow actions, and third-party module integrations. For each customization, determine whether it has an equivalent in XM Cloud, needs to be rebuilt differently, or can be eliminated. XM Cloud does not support custom .NET pipelines the way XP does, so every server-side customization needs a migration strategy.

Integration mapping. List every external system connected to your Sitecore instance: CRM, ERP, DAM, marketing automation, analytics, search, and CDN. Document how each integration works (API, database sync, custom connector) and whether the integration pattern will change in the XM Cloud architecture. Many integrations will shift from server-side to client-side or edge-function patterns.

Personalization and analytics review. If you use Sitecore’s built-in xDB analytics and personalization rules, these components do not exist in XM Cloud. They migrate to Sitecore CDP and Personalize, which are separate products with different architectures. Plan for this transition early. It affects both licensing costs and implementation timeline.

Sengo’s Sitecore audit service provides a structured pre-migration assessment that covers all four dimensions. The output is a detailed migration roadmap with effort estimates, risk areas, and recommended sequencing.

Migration Paths: Direct vs Hybrid

There are two primary approaches to Sitecore migration from XP to XM Cloud: a direct cutover and a hybrid phased approach. The right choice depends on your site complexity, risk tolerance, and business continuity requirements.

Direct migration involves rebuilding the front end in Next.js using Sitecore’s Content SDK (the official SDK for SitecoreAI; JSS 22 reaches end of life in June 2026), migrating content to XM Cloud, and cutting over completely. This approach works best for organizations with relatively straightforward sites (under 50 templates, limited custom code) and teams comfortable with a clean-break transition. The advantage is simplicity. You end up with a fully modern architecture without maintaining two systems. The risk is that it requires everything to work at launch, leaving less room for incremental validation.

Hybrid phased migration runs both systems in parallel during the transition. You might migrate marketing pages to XM Cloud first while keeping complex application functionality on XP temporarily. A reverse proxy routes traffic between the two systems based on URL patterns. This approach reduces go-live risk because you migrate section by section, validating each before moving on. However, it increases short-term complexity and requires maintaining both environments.

In our experience, most enterprise Sitecore migration projects benefit from the hybrid approach. The ability to migrate incrementally, starting with the highest-value, lowest-risk sections, gives teams confidence and stakeholders visible progress. Direct migration works well for smaller sites or complete rebuilds where the old architecture offers nothing worth preserving.

Choose your approach: lift, re-architect or replace

Before you pick a cutover style, decide how much of the current build you keep.

• Lift. Move templates and components across with as few changes as possible. It is the fastest option, but it carries old design and code debt into the new platform.
• Re-architect. Keep Sitecore, but redesign the content model, components and integrations for headless delivery. This is the most common choice for enterprise estates.
• Replace. Leave Sitecore for another platform such as Contentful, Optimizely CMS (SaaS), Storyblok or Kentico. Use the same assessment to compare the options before you commit.

Realistic migration timeline by phase

Vendor material often suggests 4 to 6 months. For a mid-sized enterprise estate, 9 to 14 months is a more realistic plan, and large multi-site estates can go past 18 months. These are typical ranges; your own scope, integration count and team decide where you land.

Two line items are often missing from plans: allow 3 to 6 weeks of rework per major integration, and 2 to 4 weeks to tune Personalize rules after launch.

For comparison, an upgrade is shorter than a migration. For the Commission de la construction du Québec (CCQ), Sengo led the upgrade from Sitecore 9 to 10, along with Coveo and Node.js, in a six-month engagement (read the CCQ story). Moving to a new platform adds a rebuild, content migration and parallel running on top of that kind of work.

Content Migration Process

Content migration is typically the most time-consuming phase of a Sitecore migration project. The challenge is not just moving data. It is transforming content from XP’s tree-based structure to XM Cloud’s component-based content model.

Step 1: Content model design. Before migrating anything, design the target content model in XM Cloud. Map XP templates to XM Cloud components and data templates. Identify where content structures need to change: for example, XP page-level fields may become component-level data sources in XM Cloud. This step requires collaboration between content strategists and developers.

Step 2: Automated extraction. Use Sitecore’s serialization tools (Sitecore CLI or third-party tools like Unicorn) to extract content items from XP as YAML or JSON. Filter out system items, unused templates, and orphaned content. The goal is a clean dataset representing only the content you intend to migrate.

Step 3: Content transformation. Build scripts to transform extracted content into the target XM Cloud format. This involves restructuring data, mapping field types, resolving internal links, and handling media references. Pay special attention to rich text fields: internal links and media references often need URL rewriting. Furthermore, multi-language content requires careful handling to maintain language versions and fallback rules.

Step 4: Import and validation. Import transformed content into XM Cloud using the Sitecore CLI or Content Management API. Run automated validation checks: verify item counts match, links resolve correctly, media assets load, and language versions are complete. Manual spot-checking by editors is essential: automated tools catch structural issues but not content quality problems.

Step 5: Iterative refinement. Plan for multiple migration runs. The first run reveals transformation issues, missing mappings, and edge cases. Refine your scripts, fix the issues, and run again. Most projects require 3-5 migration runs before achieving clean results. The final migration run happens during the go-live window.

Code Refactoring for Headless

The code refactoring phase of a Sitecore migration is where the architecture fundamentally changes. XP uses server-side .NET MVC renderings: controllers, views, and models that execute on the Sitecore server. XM Cloud uses headless architecture where the front end is a separate Next.js application that fetches content through Sitecore’s Layout Service API.

Rendering conversion. Every XP rendering needs a corresponding Next.js component. Map each MVC rendering to a React component built with the Content SDK. The rendering logic moves from C# server-side code to JavaScript/TypeScript client-side code. Data that was accessed through Sitecore’s .NET API is now fetched via the Layout Service or GraphQL endpoints. This is often the most labor-intensive part of the Sitecore migration.

Business logic migration. Custom pipelines, event handlers, and scheduled tasks in XP have no direct equivalent in XM Cloud. Business logic must move to one of three locations: Next.js API routes (for request-time logic), edge functions (for performance-critical processing), or external services/webhooks (for background processing). Sitecore’s webhook support in XM Cloud enables event-driven architectures that replace many pipeline-based patterns.

Search implementation. If your XP site uses Sitecore’s built-in Solr or Azure Search indexes, these need replacement in XM Cloud. Options include Sitecore Search (the composable product), Coveo, Algolia, or custom search implementations. The search index structure, facets, and query logic all need redesign for the headless architecture.

Form handling. Sitecore Forms from XP does not migrate directly to XM Cloud. Replace with Sitecore Forms as a composable service, or integrate third-party form solutions. All form data storage and submission logic needs re-implementation.

Throughout the refactoring process, maintain a mapping document that tracks every XP component and its XM Cloud equivalent. This document becomes the acceptance testing checklist and ensures nothing is missed during migration.

Hidden gotchas to plan for

• Language fallback. Fallback rules behave differently once content is delivered headless. Test every language explicitly, including French Canadian content.
• Media URLs change shape. Media library links move to new URLs, so rich text, redirects and external references all need checking.
• Sitecore Forms data. Forms and their stored submissions do not migrate cleanly. Export the data you must keep before cutover.
• Publishing timing. Event-driven publishing changes when content appears on the live site. Check scheduled releases and cache rules.
• Budget model. Moving from licences and servers to a subscription shifts spending from CapEx to OpEx. Model a 3-year total cost of ownership for finance early.
• Rollback. Keep XP read-only for at least 30 days after cutover before you decommission it.

Go-Live Checklist for Sitecore Migration

The go-live phase of a Sitecore migration requires meticulous planning. Missing a step here can result in downtime, broken experiences, or SEO damage. Use this checklist to ensure a smooth transition from XP to XM Cloud.

Pre-go-live (2 weeks before):

• Complete final content migration run and validate all items
• Run full regression testing on XM Cloud environment
• Verify all integrations (CRM, CDP, analytics, search) are functional
• Implement 301 redirects for any URL structure changes
• Test multi-language content and locale routing
• Validate XML sitemaps and robots.txt configuration
• Load test the XM Cloud + Next.js front end under expected traffic
• Brief the content team on the new editorial workflows in Pages

Go-live day:

• Execute final delta content migration (changes since last full run)
• Update DNS or CDN routing to point to the new front end
• Verify SSL certificates and HTTPS redirects
• Monitor error logs, performance metrics, and search console
• Test critical user journeys: homepage, key landing pages, forms, search
• Confirm analytics tracking fires correctly on all pages

Post-go-live (first 2 weeks):

• Monitor search rankings and crawl errors in Google Search Console
• Track Core Web Vitals for performance regressions
• Address any content issues reported by the editorial team
• Validate personalization rules are firing correctly in CDP/Personalize
• Decommission the XP environment once stable (keep backups)

A successful Sitecore migration is not just a technical exercise. It is an organizational change project. Content teams need training on the new editorial experience, developers need onboarding to the headless architecture, and stakeholders need visibility into progress and risks. At Sengo, we manage this end-to-end: from pre-migration assessment through go-live support and post-launch optimization.

A 90-day plan to get started

Days 1 to 30: build the picture. Run a structured audit of content, customizations, integrations and editorial workflows. Pair it with a 3-year cost model that compares staying on XP, moving to SitecoreAI and at least one other platform.

Days 31 to 60: decide the shape. Choose lift, re-architect or replace. Decide whether you adopt the full SitecoreAI suite or keep tools you already run, such as Coveo for search. Set the timeline against business milestones such as campaigns, financial close periods or audits.

Days 61 to 90: lock the team. Assign the core team, brief the steering committee and run an architecture sprint that produces the detailed backlog, budget and risk register.

Frequently asked questions

How long does a Sitecore XP to SitecoreAI migration take?

For a mid-sized enterprise estate, plan for 9 to 14 months from assessment to decommissioning XP. Large multi-site estates with many integrations can take more than 18 months. These are typical ranges, not a quote: content volume, custom code and the number of integrations decide your actual timeline.

What happened to XM Cloud?

Sitecore launched SitecoreAI on November 4, 2025 as the evolution of XM Cloud. It brings content management, customer data, personalization and search into one platform. Sitecore said existing XM Cloud customers move to SitecoreAI without a migration (Sitecore announcement).

Do we need to move from JSS to the Content SDK?

Yes, if you run on SitecoreAI. The Content SDK is the official SDK for SitecoreAI, and Sitecore asks JSS users on SitecoreAI to move to it before JSS 22 reaches end of life in June 2026 (Sitecore KB1004260).

How long is Sitecore XP still supported?

It depends on the version. Extended support for XP 10.0 and 10.1 ends on December 31, 2026, 10.2 on December 31, 2027, 10.3 on December 31, 2028 and 10.4 on December 31, 2030. XP 10.5, released in August 2026, has extended support until December 31, 2032. Since June 2026, security updates during Extended Support are a paid option (Sitecore KB0641167).

Can we keep our current search or other tools?

Yes. Many teams keep tools they already run, such as Coveo for search, instead of adopting the whole suite. Every kept tool still needs integration work, so plan 3 to 6 weeks per major integration.

Sources

• Sitecore: Sitecore unveils SitecoreAI (November 4, 2025)
• Sitecore KB1004260: Content SDK and JSS support for SitecoreAI
• Sitecore changelog: new SDK lifecycle for XM Cloud
• Sitecore KB0641167: Sitecore XP and XM support lifecycle
• Sitecore Experience Platform 10.5 release notes

Before you plan the move, check whether your organization is ready with our pre-migration checklist, or compare options in our headless CMS decision framework.

Book a migration assessment