Sitecore XP 10.5 What You Need to Know Before Upgrading

Sitecore XP 10.5 was released on August 5th, 2026, and the platform DXP upgrade is easy to underestimate if you approach it as a conventional application upgrade; however, the important changes go much deeper.

As part of Sitecore 10.5 Windows and SQL Server support move forward, Solr 10 becomes mandatory, Sitecore assemblies target .NET Framework 4.8.1, several security defaults change, Application Insights configuration is modernized, messaging dependencies move, and a number of long-standing publishing and search issues are addressed.

Additionally, depending on what current version of XP you’re on, such as 10.x or something older, the timeline for accomplishing the upgrade could either take a few weeks or a few months.

So how do you approach all of these changes now that an upgrade is on your agenda? For a containerized enterprise environment, I would frame the project as an infrastructure modernization program that includes a Sitecore upgrade.

That distinction affects sequencing, testing, rollback planning, and how the work should be estimated. Teams that treat 10.5 as an application merge tend to discover the infrastructure dependencies mid-project, when the cost of resequencing is highest. In this article, we’ll explain the key changes from XP 10.4 to 10.5, how to plan the upgrade sequence, and what you need to know before upgrading.

The Key Changes in Sitecore XP 10.5

• Windows Server 2019 container images are gone. Sitecore 10.5 container images use LTSC2022 or LTSC2025, and container hosts on Windows Server 2019 must move first.

• SQL Server 2019 is no longer supported, but SQL Server 2022 and 2025 are supported instead.

• Sitecore XP 10.5 only supports Solr 10, not Solr 8 or 9.

• Sitecore platform and component assemblies now target .NET Framework 4.8.1.

• The Package Installer and Package Designer are disabled by default through Sitecore.Packages.Disabled=true.

• The built-in GraphQL Playground has been removed.

• Application Insights configuration must use Connection Strings instead of Instrumentation Keys.

Sitecore XP 10.4 to 10.5 At a Glance

These aren’t isolated version bumps. They define the dependency order of the upgrade.

8 Steps to Approach a Sitecore XP 10.4 to Sitecore XP 10.5 Upgrade

1. Prove the platform baseline before touching the application

A 10.5 project should start with an inventory of the environment, not a merge of Sitecore configuration.

Sitecore no longer ships Windows Server 2019 container images. Its 10.5 container line is based on Windows Server 2022 and Windows Server 2025. SQL Server 2019 support has also been removed, while SQL Server 2022 remains supported, and SQL Server 2025 has been added. All Sitecore XP 10.5 platform and component assemblies target .NET Framework 4.8.1.

This means an environment using ltsc2019, Windows Server 2019 hosts, or SQL Server 2019 has infrastructure work that must happen before the Sitecore application can be considered production-ready.

Search for LTSC2019 outside your main Dockerfile

The common mistake is to update the primary CM and CD images while overlooking tooling, initialization containers, CI agents, custom base images, or scripts that still depend on the old Windows baseline.

Get-ChildItem -Path . -Recurse -File -Include Dockerfile,*.yml,*.yaml,*.json,*.ps1 |
    Select-String -Pattern 'ltsc2019|windowsservercore.*2019|servercore.*2019' |
    Select-Object Path, LineNumber, Line

Also, review build agents and self-hosted runners. A production host may support the new image while a CI machine still cannot build or execute it.

Treat the Dockerfile as a dependency inventory

Don’t copy an LTSC2019 Dockerfile, replace one version string, and assume the job is complete.

Review native dependencies, Visual C++ runtimes, certificates, trust stores, PowerShell modules, Windows features, diagnostic tools, fonts, and anything else installed directly into the image. Sitecore explicitly updated its minimum Microsoft Visual C++ Redistributable requirement in 10.5.

The objective is to prove that the platform works on the new baseline before application-specific failures are introduced.

SQL Server 2019 changes the project scope

If Master, Core, Web, xConnect, reporting, processing, or other Sitecore databases still live on SQL Server 2019, the database platform is part of the upgrade program.

Where an environment already runs SQL Server 2022 or another supported database platform, I would avoid introducing an unnecessary change to the SQL engine during the first Sitecore 10.5 production cutover. Moving Windows, Solr, Sitecore, and SQL simultaneously makes troubleshooting and rollback harder.

Module compatibility needs to be checked before estimation

As of August 7, 2026, Sitecore’s 10.5 release page still identifies several modules as undergoing compatibility verification, including SXA, Headless Rendering, Codeless Schema Extensions, Azure Blob Storage, the Publishing Service Module, and the Content Hub connector.

Before committing to a schedule, create a platform inventory like this:

If this inventory is incomplete, the estimate is mostly measuring uncertainty.

2. Solr 10 is part of the upgrade, not an optional follow-up

Sitecore’s breaking-change documentation is explicit: Sitecore XP 10.5 supports Solr 10 only. Support for Solr 8 and Solr 9 has been removed, and Sitecore recommends moving to Solr before the Sitecore application upgrade.

That makes Solr its own migration workstream.

Authentication changes deployment and secret management

Solr 10 introduces authentication requirements that affect how Sitecore container environments are configured. Sitecore separates administrative credentials used during initialization from runtime credentials used by the application.

sitecore-solr-admin-username.txt
sitecore-solr-admin-password.txt
sitecore-solr-connection-username.txt
sitecore-solr-connection-password.txt
sitecore-solr-instance.txt
sitecore-solr-port.txt
sitecore-solr-protocol.txt

Sitecore documents these as replacements for the previous combined Solr connection-string secrets.

Keep these values in the environment’s established secret-management system. Don’t roll back an authentication upgrade by committing credentials to Compose files or XML patches.

Check custom Solr provisioning

The Sitecore-managed schema filename changes from managed-schema to managed-schema.xml. Any script that copies the old filename into a core configuration should be updated.

Get-ChildItem -Recurse -File -Include *.ps1,*.cmd,*.bat,*.yml,*.yaml,Dockerfile |
    Select-String -Pattern 'managed-schema(?!\.xml)' |
    Select-Object Path, LineNumber, Line

Facets and sorting deserve regression tests

Sitecore’s Solr schema uses solr.SortableTextField for a number of field types. Because docValues preserve the original field value rather than the analyzed token stream, sorting and faceting can behave differently from older text-field configurations. Sitecore also documents a Solr pivot-faceting issue and exposes ContentSearch.Solr.UseEnumFacetMethod as a workaround.

Don’t validate this migration by confirming that a core exists.

Validate the queries the application actually depends on: language filtering, phrase searches, security trimming, category facets, wildcard resolution, SXA queries, computed fields, full rebuilds, SwitchOnRebuild, and SolrCloud behavior where applicable.

Capture representative result counts and IDs before the migration so the comparison has an objective baseline.

Solr requests now use POST by default

ContentSearch.Solr.SendPostRequests changes from false to true in Sitecore XP 10.5. Sitecore now sends queries via HTTP POST by default, addressing long-query cases that could previously result in HTTP 414 errors.

Review proxies, WAF rules, diagnostics, and request logging that assume Solr traffic uses GET.

3. NET Framework 4.8.1 is only the visible runtime change

Sitecore XP itself remains a .NET Framework application, but its platform and component assemblies move from .NET Framework 4.8 to 4.8.1. At the same time, the Sitecore Framework libraries used by platform components move to the .NET 10 servicing line, bringing major-version changes to several underlying dependencies.

The practical risk sits in custom code that references those dependencies directly.

Search for direct Sitecore.Framework.*, Microsoft.Extensions.*, Azure SDK, Rebus, and custom binding-redirect dependencies. Standard implementations may require little work. Solutions that directly extend these libraries should be rebuilt and tested rather than relying on redirects.

Telerik is another dependency boundary

Sitecore upgrades Telerik UI for ASP.NET AJAX from 2020.3.1021.45 to 2025.2.528. The NuGet package names change, a Telerik licensing runtime assembly is introduced, and custom assemblies that compile directly against Telerik packages require their own Telerik license key.

This matters most for custom editor controls and legacy modules, not standard Sitecore installations.

BinaryFormatter removal affects rollback planning

Sitecore replaces internal BinaryFormatter serialization with JSON across several data stores due to known deserialization risks.

The compatibility direction is important. Sitecore XP 10.5 can read affected data produced by older releases, but data rewritten in the new 10.5 format cannot necessarily be read by an older Sitecore version.

That means rollback cannot be reduced to “redeploy the previous image.”

Application rollback, database restoration, and one-way data-format changes require separate recovery decisions.

One lesson from a real container upgrade

During one of Oshyn’s 2026 Sitecore container upgrades, from 10.2 to 10.4, the platform came up clean while an Email Delivery integration immediately exposed a SparkPost authorization failure.

Container health did not mean the system was healthy.

That experience is why I treat a successful startup as the first gate, not acceptance. With 10.5 moving more infrastructure and dependency boundaries, integration-level testing needs to begin early.

4. Security hardening changes defaults

Sitecore XP 10.5 includes significant security hardening, including fixes for XAML cache poisoning, remote code execution paths, SPEAK path traversal, hard-coded credentials, and legacy client-side dependencies.

More importantly, for an upgrade project, some hardening changes alter runtime defaults.

Package Installer is disabled unless you deliberately enable it

Sitecore.Packages.Disabled defaults to true in Sitecore XP 10.5. Package Installer and Package Designer are therefore disabled.

Sitecore provides App_Config/Include/zSitecore.InstallPackage.Enable.config for environments that intentionally need the old behavior.

For production CM roles, I would treat re-enabling interactive package installation as an exception that needs a reason. Controlled deployments or serialization are usually easier to audit.

Item Service search is more restrictive

Sitecore adds Sitecore.Services.AllowSearchServiceAnonymousUser, which defaults to false.

Anonymous access to Item Service Search and SearchViaItem now requires both this setting and Sitecore.Services.AllowItemServiceAnonymousUser to be enabled. Sitecore also enables search security checks by default through Sitecore.Services.EnableSearchSecurity=true.

If an integration depends on Item Service Search, test it using the real service account and its permissions. A 403 after upgrade may be expected security behavior rather than an infrastructure failure.

5. Observability and messaging need explicit acceptance criteria

A homepage smoke test won’t tell you whether telemetry, Service Bus integration, or messaging SQL is healthy.

Sitecore XP 10.5 removes the Instrumentation Key-only Application Insights configuration. Platform telemetry must use Connection Strings, while affected xConnect configurations move from AppInsightsKey to AppInsightsConnectionString.

After deployment, generate real traffic on every relevant role and verify requests, dependencies, traces, exceptions, and the dimensions used by operational dashboards.

requests
| where timestamp > ago(30m)
| summarize Requests=count(),
            Failures=countif(success == false)
  by cloud_RoleName
| order by cloud_RoleName asc

Save these queries before the upgrade and use them as regression artifacts.

Azure Service Bus dependencies change

Sitecore moves from Microsoft.Azure.ServiceBus to Azure.Messaging.ServiceBus. Custom code that directly references the old SDK should be treated as a code migration rather than handled via binding redirects.

Messaging SQL has a real schema change

The Sitecore.Messaging SQL transport database also changes.

The Sitecore_Transport receive index is updated, and Sitecore_DataBus.Id moves from varchar(200) to varchar(400) with a clustered primary key requirement. Environments using Messaging SQL must run the appropriate Sitecore 10.5 database upgrade scripts.

The newer SQL client also applies stricter certificate validation. Containerized roles that use encrypted Messaging SQL connections may require the appropriate root CA to be installed when Encrypt=true and TrustServerCertificate=false.

6. Turn resolved issues into regression tests

One of the most useful parts of XP 10.5 is not a new feature. It is the collection of production-relevant defects that Sitecore fixed.

Publishing, search, authoring, headless behavior, caching, performance, and Device Detection all contain changes worth translating into acceptance tests.

Publishing behavior deserves specific tests

Sitecore fixes issues involving incremental publishing, workflow and language interaction, related items in Smart Publish, and DuplicateItemNameException.

It also introduces Publishing.CheckDuplicateNameOnPublish, enabled by default. If publishing would create a duplicate sibling name in the target database, the item is skipped, and a warning is logged.

Test against the content model your editors actually use, including multilingual items, workflow states, renamed items, datasource references, and conflicting names.

Search security and computed fields may produce different results

Sitecore fixes the unavailability of Context.Site in computed index fields during parallel indexing and corrects the propagation of the security state.

That can fix old errors, but it can also change the custom computed-field output. Compare actual indexed values before and after migration, and run the same search for users with different content permissions.

Device Detection changes its memory/performance tradeoff

DeviceDetection.PerformanceProfile now defaults to Balanced instead of LowMemory.

That favors faster lookup through caching but may increase memory usage. Sites using Device Detection should include memory consumption in their pre- and post-upgrade baselines.

GraphQL Playground is gone

The built-in GraphQL Playground has been removed. Sitecore recommends external clients such as Postman or Insomnia, and associated settings and middleware have also been removed.

For support and regression work, I prefer source-controlled API collections anyway. They can be executed consistently across development, QA, and production-like environments rather than relying on an embedded UI.

7. The upgrade sequence I would use

I prefer to organize an XP upgrade around failure domains rather than around a single application deployment.

1. Phase 1: Inventory and target matrix. Establish the current baseline for Windows, SQL, Solr modules, xConnect roles, Identity, observability, messaging, CI/CD, and custom code. Decide on the target Windows and SQL platform before development starts.

2. Phase 2: Platform readiness. Prove the new Windows container baseline, build agents, native dependencies, .NET Framework 4.8.1 targeting, and SQL prerequisites while keeping unrelated application changes out of the environment.

3. Phase 3: Solr 10 readiness. Provision Solr 10, implement authentication and secret handling, update provisioning scripts, populate schemas, rebuild indexes, and compare representative application queries.

4. Phase 4: Application merge. Start from a clean Sitecore 10.5 configuration and reapply only intentional customizations. Don’t copy an old App_Config tree wholesale. Old patches may target removed processors, restore outdated defaults, or preserve workarounds for defects that 10.5 already fixes.

5. Phase 5: Databases and Identity. Follow the topology-specific Sitecore upgrade procedures, including Messaging SQL and Identity schema work where applicable.

6. Phase 6: Integrations and observability. Validate Application Insights, Service Bus, EXM/EDS, forms, APIs, and external services. A healthy CM container is not evidence that these dependencies work.

7. Phase 7: Acceptance by failure domain.

8. Production go/no-go criteria for Sitecore XP 10.5

For a containerized enterprise deployment, I would not approve production cutover while an LTSC2019 dependency remains, a Sitecore database is still on SQL Server 2019, or Solr 10 has not been authenticated, rebuilt, and functionally validated.

Every custom assembly and module should have an owner and a clear disposition. Application Insights needs to be verified on every relevant role. Messaging database and certificate changes should be tested where applicable. Publishing, authoring, search, security, and headless regression suites need to pass. Known workarounds from the previous version need an explicit keep-or-remove decision.

Most importantly, the rollback should have been rehearsed. A document that says rollback is possible is not the same as evidence that the team can actually execute it.

What to Avoid During an Upgrade to Sitecore 10.5

I would not pair this production move with a major content-model redesign, a headless replatform, a new CDN, a serialization overhaul, a deployment-system rewrite, or an unrelated feature release.

While those projects may be worthwhile. Combining them with an infrastructure-heavy Sitecore upgrade makes fault isolation substantially harder.

Solr 10 is different. It isn’t optional scope creep. It is part of the Sitecore XP 10.5 supported platform baseline.

When to Upgrade to Sitecore 10.5

Ultimately, it depends on which version of XP you currently have.

If you are already on 10.x

This is a straightforward upgrade. Although the platform dependencies are real, the application-side work is modest, and most of the effort is retesting rather than remediation. For a standard containerized deployment, three weeks of engineering plus a regression cycle is a reasonable planning assumption, provided you’re working with an experienced partner.

If you are on 8.x or 9.x

This is a necessary and urgent upgrade. Also, since the version gap introduces changes that 10.5 alone doesn’t cover, the sensible move is to plan it deliberately and consider pairing it with a redesign or another initiative that justifies the coordination cost.

Also note that each XP release pushes an older version toward the end of support, and running an unsupported version means no security patches or hotfixes. Check your current version against Sitecore’s product support lifecycle before anything else. If your version is approaching or past its support date, then upgrading should be a priority.

How to prioritize

I would give 10.5 a high priority when Windows Server 2019 or SQL Server 2019 is preventing infrastructure modernization, when the organization intends to keep XP in service for several more years, when security hardening is a current requirement, or when production is affected by publishing or search defects that the release addresses.

I would be more cautious when a critical module is still waiting for verified 10.5 compatibility, regression automation is weak, a near-term replatform is already funded, or the team cannot produce a credible rollback plan.

The newest version is not automatically the safest project. The decision should come from operational risk, supported infrastructure, and what the environment actually depends on.

Wrapping Up

Sitecore XP 10.5 is primarily a platform-modernization release. The major story is the operating baseline: newer Windows container images, SQL Server 2022/2025, mandatory Solr 10, .NET Framework 4.8.1, changes in Sitecore Framework dependencies, tighter security defaults, Connection String-based Application Insights configuration, updated messaging dependencies, and meaningful fixes across publishing, search, authoring, headless, and performance.

For teams coming from 10.4, sequencing is the design decision that matters most:

• Prove the platform first.

• Move Solr before Sitecore.

• Inventory and rebuild custom dependencies.

• Treat databases, observability, messaging, security, and third-party modules as first-class workstreams.

• Convert fixed defects into regression tests against your real content model and workflows.

• Keep unrelated architecture changes away from the production cutover.

Sitecore XP 10.5 provides Platform DXP with a more up-to-date foundation. But getting the value from that foundation still requires disciplined upgrade engineering.

Oshyn has been a Sitecore partner for almost 20 years and runs containerized XP upgrades for enterprises. If you are considering a 10.5 upgrade and want a second opinion on sequencing, dependency inventory, or rollback planning, reach out or explore Oshyn’s full suite of Sitecore services.