Sitecore XP 10.5: A Release for the Customers Who Aren't Moving to the Cloud

10.5 ships almost no new features, and that restraint is the message. It is a currency, security, and correctness release that keeps the floor modern under the installed base, and a reminder that leaving the platform is a re-architecture, not an upgrade.

Sitecore shipped Experience Platform 10.5 on July 29, 2026. It arrived late (the version was penciled in for early 2025), and for a while it was reasonable to wonder whether it would arrive at all, given how much of Sitecore's public energy now goes to SitecoreAI. So the first useful thing to say about 10.5 is that it exists. The second is that it is almost entirely a maintenance release, and Sitecore built it that way on purpose. The shape of it tells you precisely who it is for.

If you open the release notes hunting for a headline feature, you will be disappointed, and you will also miss what the release is doing. 10.5 is a release you read for what it does not contain.

What actually shipped

Three things dominate the changelog, and none of them is a feature.

The first is currency. 10.5 adds support for Windows Server 2025, SQL Server 2025, Apache Solr 10 (including Solr 10's mandatory Basic Authentication), and it moves the platform to .NET Framework 4.8.1. It also stops shipping Windows Server 2019 container images, which is currency enforced rather than offered: container customers on that host OS have to move before they can upgrade at all.
The second is security, and this is the honest part of the release. 10.5 patches a set of real, serious vulnerabilities: a pre-authentication XAML cache poisoning attack, a post-authentication remote code execution chain, a SPEAK path traversal, and the removal of hard-coded credentials. Package installation can now be disabled by configuration to shrink the attack surface. For a self-hosted customer, who carries the security burden of the platform themselves, this is the column that matters most.
The third is correctness. Around sixty resolved issues, most of them unglamorous, two of them worth naming because they touch data you can lose. Publishing no longer deletes live pages when a non-final workflow version exists in another language. And search no longer returns items a user is not allowed to read, which is an authorization fix, not a relevance tweak. If either of those has ever bitten you in production, you know they are not minor.

The one item dressed up as a feature is a refreshed authoring visual design, which ships, in Sitecore's own words, with no functional changes.

The investment went into the floor, not the feature set. Read against the SaaS roadmap that looks like stagnation. Read against the installed base it looks like maintenance done properly, which is a different and more useful thing.

Who stays on the platform, and why

The lazy version of this conversation says anyone still on XP is simply behind. The real reasons are more specific, and most of them are about timing rather than reluctance. Some customers hold behavioral data in xDB that, for regulatory or contractual reasons, cannot move to a vendor cloud yet. Some have years of custom pipelines and back-office integrations wired straight into the platform. Some run a marketing operation on xConnect, rules-based personalization, and EXM that has no clean one-to-one on the other side. And for almost everyone, migration is a funded project on a procurement cycle, not a line item you approve in a sprint.

None of that is an argument against moving. It is an argument for sequencing the move, because the destination is a different kind of system. SitecoreAI, the platform Sitecore rebranded from XM Cloud at Symposium 2025, folds CMS, CDP, Personalize, Search, and Content Hub into one AI-native product under a single data layer (Sitecore's shift "from composable to composed"). It is not a newer version of XP. XP is a stateful DXP you run on your own infrastructure; SitecoreAI is a cloud-native platform Sitecore runs. Same content, a different generation of architecture, with a data migration and a re-integration underneath. That is why the move rewards planning, and why keeping the platform current in the meantime matters.

Both are integrated platforms now, so the real contrast is not composed versus assembled. It is who runs the infrastructure and where the data lives. The move to SitecoreAI is a re-architecture and a data migration, which is exactly why it rewards sequencing rather than a rushed lift.

Why a maintenance release is the right release for them

Here is where 10.5 stops being a boring changelog and starts being a decision.

Sitecore's Product Support Lifecycle (KB0641167) runs in three phases across roughly eight years from a version's release: Mainstream, then Extended, then Sustaining. The phase you are in decides what you get, and since June 1, 2026 it also decides what you pay. In Sustaining, where the 9.x line now sits, security patches are not available at any price. In Extended, as of that June change, production incident support and security updates are no longer part of the standard agreement, they are billed separately. Mainstream is the only phase where security updates still come with the platform, and until 10.5 the only XP version in Mainstream was 10.4, covered through the end of 2027.

A new version resets that clock. Upgrading to 10.5 moves a customer from wherever they are now, Extended and paying for patches, or something worse, back into Mainstream, where security coverage is included again. That is the practical thing 10.5 is selling, and it is selling it to exactly the customers who are not going to re-platform this year.

For a customer on 10.1 already paying for security coverage on a version whose Extended window is closing, 10.5 is not a lateral move. It is the on-platform route back to a supported, patched, included tier, bought without touching the architecture. That is worth more than any feature Sitecore could have added to this release.

Where I would not overstate this

Three caveats, because the release is easy to over-read in either direction.

First, 10.5 does not change strategic direction. The new capability, the agents, the Marketer MCP, the unified profile layer, the evolution of Experience Edge, still lands on SitecoreAI, not here. 10.5 buys runway. It does not close the gap between the two products, and a customer who reads it as XP catching up has misread it.

Second, several of the "new" platform items are Sitecore keeping step with Microsoft rather than net-new Sitecore work. Application Insights dropping Instrumentation Key support in favor of connection strings, the Azure Service Bus client moving off the deprecated library, the jump to .NET Framework 4.8.1: these are downstream of Microsoft's own deprecations. Necessary, useful, and not the same thing as platform investment.

Third, and this is the one that will actually cost you time: 10.5 is not a lift-and-shift upgrade. A cluster of changes is breaking at the infrastructure level. Windows Server 2019 container images are gone, so container customers on that host OS migrate the host first. Identity Server has been pulled out of the platform ARM templates into its own module, which changes Azure PaaS deployments. The App Insights and Service Bus changes touch configuration. There is a new minimum Visual C++ Redistributable prerequisite. The built-in GraphQL Playground has been removed (Postman or Insomnia now). Solr 10 arrives with mandatory Basic Auth, although Solr 8.x is still supported, so that one you can stage rather than rush. Scope 10.5 as an infrastructure project with a proper test pass, not a package you drop on a Friday afternoon.

The bottom line

Strip away the version number and 10.5 is a promise, not a pivot. It tells the installed base that the platform they run will stay current, secure, and supported while they decide, on their own timeline, whether and when to make the move to SitecoreAI. The near-absence of features is the correct shape for a release aimed at customers who need runway more than novelty.

If you architect on Sitecore, the two questions to carry out of this release are not about the changelog. They are about your position. Which support phase are you in, and what is that phase now costing you. And when you move the marketing stack to SitecoreAI, have you scoped it as the re-architecture it is, or are you still quietly filing it under "upgrade." 10.5 answers neither question. It just makes sure you can afford to take your time answering them.

How we're approaching this at Altudo

At Altudo we work with teams on both sides of this line: keeping XP estates patched and supportable, and scoping the move to SitecoreAI as the re-architecture it is rather than the upgrade it is sometimes sold as. In practice that means reading the support-lifecycle pressure separately from the product-marketing timeline, treating a 10.5 upgrade as the infrastructure project its breaking changes make it, and mapping an integrated marketing stack onto SitecoreAI before anyone signs up to rebuild it. When a client is ready to make that move, we run it on FastLane, our AI-powered accelerator for SitecoreAI: specialized AI agents take on the repetitive weight of the re-architecture (component creation, content migration, testing, documentation) while our delivery team keeps governance and quality control over what they produce. It is how we make the re-architecture faster without pretending it is a toggle.

If your team is weighing a 10.5 upgrade against a move to SitecoreAI, or simply wants to separate lifecycle reality from roadmap narrative, I am happy to discuss the trade-offs. Feel free to connect with me on LinkedIn, or learn more about our work at Altudo.