Sitecore XP 10.3 and 10.4 end of support: move to SitecoreAI or replace

Sitecore XP 10.3 and 10.4 end of support: what your options are

Sitecore XP 10.3 and 10.4 estates face two dated decisions: Sitecore 10.3 mainstream support ended in December 2025, and 10.4 follows in December 2027. You can upgrade within XP, port to SitecoreAI, or move to an open-source CMS. SitecoreAI is SaaS only. It is the composable CMS formerly called XM Cloud, it requires Headless SXA, so existing MVC sites must be ported to Next.js, and it has no xDB. An open-source CMS can run in your own infrastructure, which is the path to take if hosting location is a fixed requirement.

Start with an inventory that answers three questions before choosing a path. Which MVC renderings and sites would need a Next.js port? Which features depend on xDB, personalization rules, EXM or Marketing Automation? Sitecore's XM/XP to SitecoreAI migration guide states that xDB data, email marketing content and personalization do not migrate and must be rebuilt. Ask Sitecore or your implementation partner to confirm which of your features fall into that group. Upgrading within XP keeps those features but still leaves December 2027 to plan around, so the inventory is needed on every path.

Open-source options differ mainly in the skills they need and in who hosts them. Drupal runs on PHP, Wagtail on Django, Umbraco on .NET, and Strapi and Payload suit teams building a Node.js front end. Each can run in your own data center or cloud account. Choose by your team's skills and the content model you need, then confirm current support, licensing and hosting terms with each vendor before you scope. Much of the effort sits in rebuilding renderings and personalization, so scope that work first.

What the end-of-support date requires from you

Sitecore 10.3 mainstream support has already ended, and 10.4 follows in December 2027. The cards below are the questions your team needs answered before choosing a path, because each one changes how much rebuild work the move requires.

Confirm your current support dates

Sitecore 10.3 mainstream support ended in December 2025, and 10.4 runs until December 2027. Confirm the exact support status of your installed version, including any extended or custom agreements, with Sitecore and your licensing contract. Record the date your estate must be off the current version, because it sets the planning window for every other decision.

Choose a path before support ends

Your options are an in-place upgrade within XP, a port to the SaaS SitecoreAI, or a move to an open-source CMS. Each option needs a different amount of build, content and testing work, so the choice should be made early enough to run a pilot and a parallel period. Ask each candidate partner to scope the path in writing before committing budget.

Check for MVC renderings

SitecoreAI requires Headless SXA, so existing MVC sites must be ported to Next.js. Inventory your MVC renderings, controllers, view models and custom pipelines to estimate how many components must be rewritten rather than configured. If most of the front end is MVC, the rebuild effort is the main cost driver regardless of which platform you choose.

Decide whether xDB and personalization stay

Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, so these must be rebuilt. List which personalization rules, campaigns, forms and analytics reports your marketing team uses weekly. Some features, such as Marketing Automation, EXM and Path Analyzer, have no SitecoreAI equivalent, so plan separate tools for them.

Confirm hosting location requirements

SitecoreAI is a SaaS platform, so it cannot be hosted in your own data center or air-gapped network. Document any regulatory, contractual or data residency rule that requires the site, its databases and its analytics to run on infrastructure you control. If such a rule applies, SitecoreAI is excluded and the comparison narrows to self-hosted options.

Plan the content and access exit

Confirm what you can export before you commit to a new platform. Sitecore Content Serialization covers items, roles and users in YAML, but xDB, personalization rules and analytics have no export path. Ask your team to test an export of a representative subtree, check user and role mappings, and confirm that media and multilingual content arrive intact before the migration plan is approved.

Three paths and the rebuild work each one needs

Staying on Sitecore XP keeps the current architecture, so the work is mostly an upgrade and regression exercise. The supplied facts do not cover the XP upgrade path, so confirm the supported target version, prerequisites and tooling with Sitecore before you plan.

Platform upgrade: Move the solution, custom modules and infrastructure to a release Sitecore still supports, then check each dependency against the new version.
Marketing stack: Marketing Automation, EXM and Path Analyzer stay in place, so their hosting, licenses and database servers remain on your upgrade schedule.
Custom code and renderings: Expect regression testing on MVC renderings, pipelines and custom components, since these carry most of the risk.
Recurring cost: Licenses or subscriptions, plus the hosting and database estate, continue, and the end-of-support question returns at the next version.

Check the exact target version, its end-of-support date and whether your licensed features still apply before you commit budget to this path.

Which open-source CMS fits which Sitecore estate

This table compares Drupal, Umbraco, Wagtail, Strapi and Payload by license, language and runtime, hosting control, headless delivery and fit for multi-site and multilingual Sitecore estates. Read each row against your team's skills and whether you plan a server-rendered site or a Next.js frontend. Strapi Enterprise code and Directus are excluded from the shortlist for licensing reasons.

Platform	License, language and runtime	Hosting control and headless delivery	Fit for multi-site and multilingual estates
Drupal	GPL-2.0-or-later, PHP. Drupal 11 requires PHP 8.3 or later.	Runs on Apache or Nginx with MariaDB, MySQL, PostgreSQL or SQLite. Decoupled delivery needs a separate frontend build.	Built for large multi-site estates. Confirm module choices and multilingual setup during scoping.
Umbraco	MIT license, C#. Requires .NET 10.0 or higher with SQL Server or SQLite.	Self-hosted or on Umbraco Cloud on Azure. The Content Delivery API is opt-in for headless builds.	Suits .NET teams keeping C# skills. Engage and Forms need paid licenses on public domains. Confirm multi-site and language needs.
Wagtail	BSD-3-Clause license, Python on Django 5.2, 6.0 or 6.1.	Self-hosted with a headless API. Torchbox offers commercial support and hosting.	Multi-site and multi-language are built in. Personalization and marketing features need separate tools.
Strapi	Community Edition under MIT. Code in ee/ directories falls under the Enterprise license.	Self-hosted Node.js with REST and GraphQL APIs. The Next.js frontend is built separately.	Content types suit headless rebuilds. Confirm multi-site and locale handling. SSO and audit logs may sit in paid plans.
Payload	MIT license, TypeScript, installs into a Next.js /app folder.	Self-hosted on MongoDB or PostgreSQL. Tightly coupled to a Next.js frontend.	Fits teams already building Next.js front ends. Confirm multi-site and localization configuration in your build.
Excluded from shortlist	Strapi Enterprise Edition code and Directus under MSCL-1.0-GPL.	Directus is not an OSI open source license and bars competing use.	Ask counsel to review license terms before any use in a Sitecore replacement.

How to run the replacement in your own infrastructure

This sequence moves a Sitecore XP estate from inventory to a parallel environment on infrastructure you control, then cuts over and retires XP in a controlled order. Each step ends with a written output the business and engineering owners can sign off before the next one begins.

Inventory renderings, content, media and integrations
Your Sitecore architects and content owners list every site, site definition, rendering, template, media library, workflow, form and integration with CRM, search, identity or marketing tools. DeployOpen can run this inventory against your environment if it is in scope. You know it is done when each item has an owner, a target disposition (migrate, rebuild, retire or keep) and a record of which XP features it depends on, including xDB, Marketing Automation, EXM and Path Analyzer, which have no SitecoreAI equivalent.
Choose the target platform and hosting model
Leadership, security and platform engineering compare the three paths against your hosting requirements, including whether content must stay in your own data center or cloud accounts. Confirm with Sitecore whether SitecoreAI meets your hosting and data residency needs before you rule it in or out. The output is a signed decision record that names the CMS, the hosting location, the database and who operates each layer.
Build the parallel environment
Platform engineers provision the target CMS, database, search, storage and CI/CD pipeline in your infrastructure, with separate development, staging and production environments. Keep the existing Sitecore estate running throughout. The step closes when a test build renders a representative page with its real content model, passes your security baseline and has backups and restore tested in a non-production environment.
Migrate content, media and redirects
Content engineers map Sitecore items and languages to the target content model, script the import of content and media, and preserve URL structure with redirects where paths change. Confirm what your export tooling carries over, since the Sitecore export path covers serialized items but not xDB or analytics data. Validate with a sample of pages per site and language, comparing counts, published status, media references and broken links against the source.
Rebuild personalization, forms and marketing flows
Product owners decide which personalization rules, forms and email journeys are still needed, then rebuild them on the target platform or on separate tools. Sitecore's migration guide states that xDB data, email marketing content and personalization do not migrate to SitecoreAI, so each one needs a named replacement and an owner. The step is complete when each form submits to the intended destination, consent and retention settings are confirmed by your privacy team, and each campaign has a tested rebuild.
Run acceptance testing and cut over
Business owners, QA and security testers run functional, accessibility, performance and security tests against the parallel environment, then agree a cutover window and DNS plan. Keep Sitecore in read-only mode for a rollback period you set with your stakeholders. You know the cutover is done when acceptance sign-off is recorded, monitoring shows expected traffic on the new platform and the rollback plan has been rehearsed.
Decommission XP and retain evidence
Platform and compliance teams stop Sitecore services, archive the final export and databases according to your retention policy, and revoke licenses and credentials. Confirm with your license holder and contract team what notice and termination steps apply. The step closes with a decommissioning record that lists archived data, locations, owners and the access controls that remain in force, which helps your compliance assessment.

Evidence to keep for the migration and the new platform

Whether the path is an XP upgrade, a SitecoreAI port or an open-source rebuild, auditors and internal reviewers ask for the same core records: what existed, what moved, what was tested and who approved each change. Keep these records as you go rather than reconstructing them at cutover.

Inventory of XP components

Record every XP and XM component in scope: site collections, templates, renderings, roles, users, workflows, marketing modules such as Marketing Automation, EXM and Path Analyzer, and any custom integrations. Mark each as migrated, rebuilt, retired or replaced. The migration guide notes that SitecoreAI has no equivalent for several XP marketing features, so the inventory is where those gaps become visible to the business. Confirm the scope with your Sitecore partner in writing.

Data export records

Keep a dated record of every export: the tool and version used, the scope, file checksums, item counts and any items that failed. For XP, this covers serialized items and media. For xDB, personalization rules and analytics, record that they do not carry over, along with where the source data was archived and who can access it. Reviewers will ask whether the export was complete and who verified it.

Rebuild sign-off

For each rebuilt rendering, form, personalization rule and campaign, keep a sign-off showing the business owner accepted the new behavior. Include the test scripts, the environments tested and the defects found and closed. Where a feature is dropped, record the decision and the approver. This record protects the organization if a visitor-facing function changes after launch.

Access control and SSO configuration

Document how editors, administrators and service accounts authenticate on both the old and new platforms, including SSO federation settings, role mappings and the list of accounts with publishing rights. Export the role model from XP before decommissioning. Reviewers commonly test whether leavers and contractors lost access on time, so keep the access review results for the cutover period.

Backup and restore test results

A backup is only evidence once a restore has been performed. Record the date of each restore test, the platform restored, the time taken, the data checked afterward and any gaps found. Keep the XP databases and content stores as read-only archives until the retention decision is signed off. Ask your hosting or implementation partner to show these results before the old environment is decommissioned.

Change records

Keep a change log for every configuration, code and infrastructure change from the first upgrade step to go-live, with the requester, approver, reason and rollback plan. Link each change to its test evidence. Auditors use this trail to confirm that production changes followed the agreed process, so store it where it cannot be edited after the fact.

Questions buyers ask before choosing a path

Can we still upgrade within Sitecore XP after 10.3 support ended?

It may still be possible, but the window is narrowing, and you need to confirm it with Sitecore before committing budget. Sitecore 10.3 mainstream support ended in December 2025, so a 10.3 estate is already past mainstream support. Sitecore 10.4 mainstream support runs until December 2027. An upgrade within XP still raises the same questions as any version move: you need an inventory of custom renderings, modules, search indexes and xDB usage, and you need to confirm that each third-party module supports the target release. Ask Sitecore for its current support statement in writing.

What does SitecoreAI require from an existing Sitecore site?

SitecoreAI is a composable SaaS CMS, and Sitecore states that it requires Headless SXA. Existing MVC sites therefore have to be ported to Next.js, so the front-end layer must be rebuilt. In practice, the port covers:

Replacing MVC renderings with Headless SXA components
Building Next.js front ends for each site template
Mapping content and presentation to the SitecoreAI model

Sitecore's migration guide also states that xDB data, email marketing content and personalization do not migrate and must be rebuilt. Marketing Automation, EXM and Path Analyzer have no SitecoreAI equivalent, so plan separate tools for those functions.

What cost and effort drivers apply to a Sitecore exit?

Cost falls into one-time work and recurring spend, and each component pays a different party. One-time costs include the implementation partner or internal team for the front-end rebuild, content and media migration, rebuilt personalization and forms, and testing. Recurring costs include the Sitecore licence or SaaS subscription until you stop paying it, hosting, upgrades, security patching and any separate marketing tools. The main drivers are the number of sites, languages, templates and renderings, the volume of personalization rules and content, the number of integrations, and how much of the xDB logic the business still uses. Ask for a quote itemized by these components, with the assumptions for each.

How long does a Sitecore migration usually take?

No reliable duration can be given from the research for this page, so treat any single number with caution. The schedule depends on the number of sites and templates, the number of languages, how complex the renderings are, how much xDB and personalization must be rebuilt, the number of integrations, and your approval and change-freeze windows. A short discovery phase is the practical way to set a timeline. DeployOpen works on fixed scope, so scope, deliverables and timelines are agreed in writing before work starts.

What does our team need to provide for a migration?

The migration depends on inputs that only your organization can supply. Expect to provide access to the Sitecore environments and exports, a content and media inventory, named owners for each site and market, and decisions on which personalization and forms logic is still needed. You also need hosting and network approvals, DNS and SSO details, test accounts for each role, and editorial time for content checks and user acceptance testing. Agree these responsibilities in the written scope so that delays in access or decisions are visible early.

Can our in-house team do the Sitecore exit without a partner?

Yes, if your team already has the skills for the target stack and time to carry the work. The SitecoreAI path needs Next.js and React skills, Drupal needs PHP, Wagtail needs Python and Django, and Umbraco needs C# on .NET. After go-live, a self-hosted platform also needs an owner for backups, patching, monitoring and security testing. Many teams keep content governance and editorial work in-house and bring in outside help for the migration and hardening. Scope the split in writing, and confirm which skills are missing before you decide.

Which open-source CMS fits a Sitecore exit if we must self-host?

Drupal, Wagtail and Umbraco are the main self-hosted options for a Sitecore estate, and each has licensing and lifecycle facts to check. Drupal is licensed GPL-2.0-or-later with no paid edition of Drupal itself, and Drupal 11 is the current major version, requiring PHP 8.3 or later. Wagtail is BSD-3-Clause, and Wagtail 7.4 LTS has security support until November 2, 2027. Umbraco is MIT-licensed, and Umbraco 17 is an LTS release with end of life on November 27, 2028, running on .NET 10. Choose by team skills and by the lifecycle dates you can support.

Running XP and the new platform during migration

Keep the XP estate live until the replacement has passed its own acceptance tests, and write that rule down before the build starts. The practical question is not whether both platforms can run in parallel, but who owns each site during the overlap. Agree a content freeze window per site with the editorial owners, and decide whether freezes apply to the whole estate or to individual sites. Confirm with Sitecore which XP 10.3 or 10.4 patch level and which support path your contract covers, because that determines how long you can keep XP in production and what security fixes you can still expect while you run both stacks.

Plan DNS and redirects as a separate workstream with its own cutover checklist. Inventory every public hostname, language prefix, campaign URL and legacy path that XP serves, then map each one to its new location and status code. Lower DNS TTLs ahead of cutover so that a rollback is possible, and keep the XP front end reachable on its original hostnames until the redirect map has been tested against real traffic logs. Ask your SEO and analytics teams to sign off on the map, since broken redirects are the most common way a migration loses search visibility and campaign attribution.

The xDB and personalization gap needs a decision before the first content freeze, not after. Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, so those rules, segments and contact histories must be rebuilt or retired. Export what you are contractually and legally permitted to keep, record which personalized experiences are live on which pages, and decide which of them must have a replacement at launch. Run the new site with the personalization features switched off for a defined test period, and confirm with Sitecore exactly which XP data stays readable in your XP instance after the SaaS move.

How DeployOpen plans and deploys the move

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Sitecore XP 10.3 and 10.4 end of support, we start with a written scope that decides between an in-place upgrade, a SitecoreAI port or an open-source replacement, then build and hand over only what that decision requires.

How we scope

We inventory sites, templates, renderings, languages, integrations and the XP modules in use before choosing a path.
We map which features have no SitecoreAI equivalent, such as xDB, Marketing Automation, EXM and Path Analyzer, and flag them in the written scope.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts; ongoing support is available as a retainer.

How we build

We build the target stack in your own cloud account, data center or air-gapped network, with the hosting model you choose.
We rebuild renderings, content models, identity integration and forms, and test them against content migrated from a staging copy.
We run security testing on the new applications and APIs and record the results as part of the delivery.

How we hand over

We document architecture, configuration, backup and restore procedures, and the rebuilt personalization or marketing replacements.
We prepare the controls and evidence your compliance team needs for assessment; auditors and certification bodies issue any attestations.
We run a cutover rehearsal, agree a rollback plan, and hand over the environment with runbooks your own team can operate.

How we support

Support, upgrades and continuous testing are available as retainers after handover, scoped in writing.
We track the Sitecore and target-platform lifecycle dates you need to plan around, and confirm them with you at each review.
We agree in writing who patches, backs up and monitors the platform after go-live, so responsibilities are clear.