The first 10.5 conversation I had went like this. A two-line Jira ticket — "Upgrade platform to Sitecore XP 10.5" — with a three-week estimate attached, because 10.3 to 10.4 took about that long. Then somebody pulled up the requirements page and the room went quiet. Solr 10. SQL Server 2019 dropped. Identity Server out of the main ARM templates. BinaryFormatter gone.
That is not a Sitecore upgrade. That is an infrastructure project with a Sitecore upgrade sitting on top.
XP 10.5 shipped on August 5, 2026. Read the release notes hunting for features and you'll come away underwhelmed — a refreshed authoring UI, some performance work. Features were never the point. This release pulls classic XP onto current infrastructure and closes off a long tail of security surface, and almost every change lands outside the Sitecore solution: on your Solr cluster, your SQL estate, your ARM templates, your WAF, and the parts of your codebase nobody has opened since 2019.
The floor moved, not the ceiling
Most upgrades add capability on top of what you have. 10.5 raises the lower bound instead.
|
Component |
10.4 |
10.5 |
Impact |
|
Windows Server |
2019, 2022 |
2022, 2025 added |
2019 container images dropped |
|
SQL Server |
2017, 2019, 2022 |
2022,
2025 |
2019 no longer supported —
remediation item |
|
Solr |
8.x / 9.x |
10
only |
Hard requirement, no fallback |
|
.NET Framework |
4.8 |
4.8.1 |
Retarget solution + build agents |
|
Identity Server |
In platform ARM template |
Separate
module + ARM template |
PaaS topology change + data
migration |
|
BinaryFormatter |
Available |
Removed |
Code change, not a config toggle |
Read that table as two parallel workstreams rather than one: infrastructure remediation, and the solution upgrade. They meet when you can stand up a working 10.5 environment. Running them sequentially is how three weeks becomes three months.
Solr 10 is where the time goes
Solr 10 is mandatory, it requires Basic Authentication, and Sitecore's search requests now go out as POST rather than long GET query strings. Credentials can live in the connection string:
<!-- App_Config/ConnectionStrings.config -->
<add name="solr.search"
connectionString="https://solr-user:S0lrP%40ss@solr.internal.example.com:8983/solr" />
That password is URL-encoded. An @ or : from a generated password produces a malformed URI, and the errors read like network failures rather than credential failures. The connection string is also now a secret — if your pipeline treats ConnectionStrings.config as a checked-in artifact, you've committed Solr credentials to source control.
The POST change surprises people, because the breakage isn't in Sitecore or Solr:
Both failure classes surface identically from the Sitecore side, which is why they eat a day:
|
Symptom |
Usually
actually is |
Where
to look first |
|
Index rebuild fails, Solr logs
show nothing arriving |
Proxy blocking or stripping POST |
WAF / reverse proxy rules |
|
401s during indexing |
Missing or mis-encoded Basic Auth
credentials |
Connection string encoding, Key
Vault reference |
|
Custom search returns empty, no
errors |
Hand-built query URL or direct
schema access |
Your own Solr integration code |
|
Segment counts stop dropping after
rebuild |
Solr optimize no longer runs
automatically |
Nothing — fix the dashboard, not
the platform |
That last row is a deliberate improvement — automatic optimize on a large index is expensive and Solr hasn't needed it routinely for years — but if a runbook or monitor was built around it, someone will file a bug.
Your own code needs the hardest look. Custom SolrNet usage, computed fields reaching into the schema, anything building a query URL by hand. Inherited a solution with a bespoke search abstraction layer? Budget real time. This is the area where "we'll fix it during regression" turns into a rewrite.
That last row is a deliberate improvement — automatic optimize on a large index is expensive and Solr hasn't needed it routinely for years — but if a runbook or monitor was built around it, someone will file a bug.
Your own code needs the hardest look. Custom SolrNet usage, computed fields reaching into the schema, anything building a query URL by hand. Inherited a solution with a bespoke search abstraction layer? Budget real time. This is the area where "we'll fix it during regression" turns into a rewrite.
Identity Server 8 moves out
Decoupling is the right call — Identity Server has its own patch cadence and pinning it to the platform release train was always awkward. The practical cost is that your Azure PaaS architecture and IaC change, and there is a data migration rather than a fresh install.
That migration is the step people skip. A clean Identity Server starts up happily, then fails to authenticate existing users — and because it presents as a login problem rather than a deployment problem, it gets found by whoever logs in on a Friday afternoon.
|
Pin
down early |
Why |
|
IdS data migration |
Fresh install ≠ working auth for
existing users |
|
Client IDs / secrets for CM and
custom clients |
Secrets now cross an extra
deployment boundary |
|
Redirect URIs |
Must match the new topology |
|
Custom IdS plugins (ADFS, Entra
ID, custom login) |
Move with the module — need their
own build/deploy path |
|
Application Insights config |
Connection strings only;
instrumentation keys are gone |
App Insights deserves its own flag: a one-line fix per environment that, missed, makes a deployment look successful while telemetry quietly goes nowhere.
Security by default, and what it costs you
The security work is the part I'm most positive about and the part most likely to break a build.
|
Change |
What
breaks |
What
you do |
|
BinaryFormatter removed |
Custom caching, session state,
object serialization — yours or a third party's |
Real serialization change (System.Text.Json,
protobuf). Grep for it before planning anything |
|
Package Installer / Designer
disabled by default |
Any deployment pushing .update or .zip
through the installer |
Move to serialization-based
deployment; if you must, enable explicitly in non-prod only |
|
Deprecated JS libraries removed |
Shell extensions and custom
Content Editor UI leaning on whatever jQuery sat in /sitecore/shell |
Audit custom shell UI dependencies |
|
GraphQL Playground removed |
Developer workflow |
Postman, Insomnia, or Altair
against the endpoint |
|
Microsoft.Azure.ServiceBus → Azure.Messaging.ServiceBus |
Compile break on any messaging
code |
Update references and API calls |
|
Vulnerability chains fixed,
dependencies tightened |
Nothing |
This is the argument for the whole
project |
The first two are unambiguously correct decisions. The installer is a remote code execution primitive by design; leaving it enabled on a production CM has caused real incidents.
The quiet operational wins
|
Change |
Why
it matters |
|
CD profiling processors disabled |
Removes overhead that had no
business on a delivery server |
|
Cache operations avoid global
locks |
Fixes the intermittent slowdown
under load that never reproduces in test |
|
MVC rendering optimized |
Noticeable in multi-site solutions |
|
Batched Recycle Bin deletion |
No more twenty-minute lock during
a large archive purge |
None of these need action. They're why a 10.5 environment feels better under load, and useful ammunition when someone asks what the business gets from an upgrade with no visible features.
Pre-flight before you touch a package
|
Audit |
Look
for |
If
it's a problem |
|
OS / SQL versions per role |
Windows Server 2019 containers,
SQL 2019 |
Infra remediation with its own
lead time |
|
Solr |
Version and topology |
Solr 10 may mean a new cluster,
not an in-place upgrade |
|
Solution |
BinaryFormatter, hand-built Solr
queries, ServiceBus refs |
Code work — size it before
committing to dates |
|
Shell extensions |
Client-side library assumptions |
Rewrite against current libraries |
|
Third-party modules |
Written 10.5 compatibility
confirmation per module |
One unshipped module holds the
whole project |
Get that last row done in week one. Finding it in week six is the classic way these projects slip.
Then upgrade in a throwaway environment first, on the new infrastructure, with migrated Identity Server data in place. Regression-test search hardest — that's where the bodies are.
What I'd tell a teammate
Don't let this be estimated as a Sitecore upgrade, because the Sitecore part isn't the hard part. Solr 10 and Identity Server 8 reshape your architecture, and both touch teams outside the Sitecore team — infrastructure, networking, whoever owns the WAF rules. Get those people into planning rather than into the incident call.
The security posture is the strongest argument for doing it. Removing BinaryFormatter, disabling the Package Installer, closing the vulnerability chains — that's the platform taking responsibility for defaults that used to be yours to remember. If you're running classic XP and expect to keep running it for a few more years, this release is what makes that a defensible plan rather than accumulating risk.
It just costs more than the release notes make it look.
No comments:
Post a Comment