How Do You Upgrade Sitecore from 9.x or 10.x to 10.4 or 10.5?

Verified October 19, 2026. Checked against Sitecore's upgrade guides and compatibility tables.

Assess, choose the path, upgrade in stages, test, cut over

You do not patch the running site. Since 10.1, Sitecore's documented method is side by side: upgrade the databases, install the new version next to the old one, attach the databases, deploy your solution, then run post-upgrade steps.¹ From 8.1 or later you can go straight to any version, so 9.x and 10.x need no stepping stones.¹

The work splits into five stages:

1. Assess what you run: version, update, topology, modules, customizations.
2. Choose 10.4 or 10.5, and the on-premises or container path.
3. Upgrade in stages: databases, clean-up, new install, solution, post-upgrade steps.
4. Test on a copy until the run is boring.
5. Cut over with a rollback you have rehearsed.

Why the clock matters

Sitecore's product support lifecycle article puts 10.0 and 10.1 at the end of extended support on 31 December 2026. Mainstream support runs to 31 December 2027 for 10.4 and 31 December 2029 for 10.5. Since 1 June 2026, security fixes in the extended phase are no longer included by default. The full table and the upgrade or migrate decision sit in our support dates guide.

Stage 1: assess what you run

Pin down the exact version

"10.3" is not enough. The update number decides which Solr versions you can use, and XM versus XP decides whether xDB steps apply. Our Sitecore version checker gives you the starting point; confirm it against the assembly versions on your servers.

Know your hosting model

The main upgrade guide says its instructions are only valid for on-premises solutions.¹ Container installs follow a separate upgrade container guide.² If you run on Azure PaaS or Managed Cloud, confirm with Sitecore or your host which documented path applies before you plan anything.

Inventory modules and customizations

Modules are not upgraded by the platform guide. It tells you to find the matching version of each module and run only the pre-upgrade steps in that module's own upgrade guide.¹ List every module, connector, config patch, custom pipeline processor and integration. In our experience, that list drives the effort far more than the platform itself.

Stage 2: choose 10.4 or 10.5, and your path

10.4 or 10.5

10.5 buys two more years of mainstream support. The catch is the ecosystem. Sitecore's modules table, last updated 11 September 2026, lists no SXA release for 10.5 yet, and marks SXA, JSS 22.x, Azure Blob Storage and the Content Hub connector with a note that 10.5 support "will be provided soon".³ In our view, a site built on SXA should target 10.4 today or wait for that table to change.

What Sitecore documents for each starting version

The 10.5 guide lists the database scripts to run, in order, per starting version.¹

Script H targets the security database if you split it from core, otherwise core.¹

xDB steps if you run XP

The xDB Data Migration Tool is only for 8.x sources; from 9.x or later you skip it.¹ Instead, you work through the guide's "Update xDB" chapter and perform every step introduced after your starting version. Upgrading from 9.0.2, for example, means every applicable step from 9.0.2 through 10.0.1.¹ Collection databases have their own update tool in the appendix.

The container path

Since 10.0.1, Sitecore ships an upgrade container that upgrades XP and xConnect SQL databases on-premises, in containers or in Azure SQL, under Docker Compose or Kubernetes.² The 10.5 artifacts only cover 9.3.0 to 10.4.0 sources, only SQL databases, and modules must be upgraded separately.² If your container site is older than 9.3.0, these artifacts do not cover it, so confirm the route with Sitecore before you plan.

Stage 3: upgrade in stages

Databases first

Back up everything, then run the scripts once per database in the documented order.¹ If you use an out-of-process session provider on SQL Server, the guide says to use the new clean Sessions database. Since 10.1, all databases deploy with least privileged users by default, so older sites may need new database users.¹

Clean up the content databases

Default items now live in resource files, so Sitecore.UpdateApp removes unmodified default items from Core, Master and Web.¹ Items you modified are not removed; the tool logs them. Review that log carefully. It is often the first honest map of who changed what in your instance over the years.

Install, attach, deploy

Install the new version beside the old, connect it to the upgraded databases, then deploy your solution.¹ Before that, update NuGet references, recompile against the new Sitecore assemblies, fix breaking changes, move every config change into separate patch files, and edit Web.config and other non-patchable files by hand.¹

Post-upgrade steps

The guide's post-upgrade chapter covers xDB maintenance, EXM configuration, Identity Server, rebuilding the reporting database, and updating the Solr schema then rebuilding indexes.¹ For 10.5 it adds a data step: users in packages and serialized files, plus the ClientData and VisitGeoIpData tables, move to a new format that older versions cannot read once overwritten.¹

What usually breaks

Config patches and custom pipelines

Anything compiled against Sitecore assemblies must be rebuilt and retested.¹ The 10.5 breaking changes list adds specifics: the Package Installer and Designer are disabled by default, Application Insights needs connection strings instead of instrumentation keys, and Sitecore Framework libraries move to the .NET 10 servicing line. Solutions that pin those packages or rely on binding redirects should recompile, not patch around.

Modules

Module versions are tied to platform versions. Sitecore's table pairs Headless Rendering 22.x and JSS 22.x with 10.4, and Headless Rendering 23.x with 10.5.³ Connectors such as Salesforce CRM and Dynamics 365 have one listed version per platform release, ending at 10.4.³ A module not in the table is not supported unless it has its own table.

Solr

This is the most common hard stop. The Solr table lists 8.11.2 to 8.11.4 for 10.3 and 10.4; 9.8.1 needs 10.3 Update-3 or 10.4 Update-1; 9.10.1 is listed for 10.4; and 10.5 lists only Solr 10.0.0.⁴ Sitecore also notes Solr 8.x reached end of life on 25 October 2024.⁴ The 10.5 breaking changes list says to upgrade Solr before Sitecore, with no backward compatibility path.

Custom Solr schema

If you customized the managed schema or wrote a schema populate helper, the 10.5 guide says both need changes for Solr 10.¹ Text fields you sort or facet on may need to switch field types. Test search results page by page, not just "the index rebuilt".

SXA

The SXA rows in the modules table pair each SXA release with exactly one XP version: SXA 10.3.0 with XP 10.3, SXA 10.4.0 with XP 10.4.³ So an SXA site upgrades SXA in lockstep with the platform, and today that stops at 10.4.

.NET Framework

Sitecore's compatibility table lists .NET Framework 4.8 for 9.3 through 10.5, and 4.8.1 for 10.5 only.⁵ Coming from 9.0 to 9.2, your site ran on 4.6.2 to 4.7.2, so every custom project changes target framework. The table also says the targetFramework attribute of httpRuntime and compilation must match.⁵

SQL Server and Windows Server

10.4 lists SQL Server 2019 and 2022; 10.5 lists 2022 and 2025, and drops 2019.⁵ Windows Server 2019 is listed up to 10.4, and 10.5 adds Windows Server 2025.⁵ On 10.5 the database server upgrade often comes before the Sitecore upgrade.

Serialization tooling

Sitecore's table lists Sitecore CLI management services versions for XP 10.1 to 10.4, and none yet for 10.5.³ If you serialize with TDS or Unicorn, check those projects directly; Sitecore's tables do not cover them. Either way, rerun a full serialization sync on the upgraded instance before you trust it.

Testing and cut-over

Rehearse on a copy

Sitecore recommends testing the upgrade on a test or developer system first.¹ The container guide is blunter: the database upgrade is irreversible, so verify it in an isolated environment and repeat it for each environment.² In our practice, the production run should be the third or fourth time the team has done it.

What to test

Our checklist: authoring in Content Editor and Experience Editor, workflow and publishing, every search page, forms and their submissions, personalization rules, xConnect data flow on XP, each integration, and load under realistic traffic. Compare against the old site, not against memory.

Cut over

Side by side helps here. Freeze content, take final backups, run the database upgrade on production copies, point the new instance at them, then switch traffic. Rollback means switching traffic back to the old instance and its pre-upgrade backups, because upgraded databases do not go back.²

When migrating to SitecoreAI makes more sense

Upgrading keeps XP features, your code and your hosting model, and resets the support clock. If you plan to rebuild the front end, or no longer want to run Sitecore servers, upgrading first can be wasted effort. Sitecore's migration guidance says an upgrade before a move to SitecoreAI is not always required. We cover that road in how to migrate from XP or XM to SitecoreAI, and our upgrade assessment compares both for your site.

References