Umbraco 15 was released on November 14, 2024. Built on .NET 9, this Standard-term Support release focused on performance for content-heavy websites, more efficient multilingual content management, secure system-to-system integrations and an improved editing experience.
While Umbraco 14 introduced the new backoffice and Management API, Umbraco 15 developed that modern foundation further. Its most important additions included a lazy-loaded content cache powered by HybridCache, block-level variants, client credentials and a new Tiptap-based Rich Text Editor.
Important update: Umbraco 15 reached End-of-Life on November 14, 2025. It no longer receives fixes or security patches from Umbraco HQ. If your website still runs on version 15, it should be treated as the starting point for an upgrade—not as the target version for a new migration. For most projects planning an upgrade today, Umbraco 17 LTS is the more appropriate destination.
.NET 9 and C# 13
Umbraco 15 runs on .NET 9 and ASP.NET Core 9. Microsoft focused this release on cloud-native applications and performance, with improvements to garbage collection, runtime optimisation, JSON handling, monitoring and tracing. ASP.NET Core 9 also introduced better static-asset handling and built-in OpenAPI document generation.
Developers can also use C# 13 features such as params collections, improved locking semantics, partial properties and indexers, and broader support for ref struct types.
For an Umbraco project, a newer runtime does not automatically make every page faster. However, it provides a stronger platform for efficient, observable and maintainable applications—especially when the application code, caching and hosting configuration are designed correctly.
A Standard-term Support release
Unlike Umbraco 13 and Umbraco 17, version 15 was an STS release. STS versions give teams earlier access to new platform capabilities, but they have a considerably shorter support lifecycle than LTS releases.
| Version | Release date | Release type | Security phase started | End-of-Life |
|---|---|---|---|---|
| Umbraco 15 | November 14, 2024 | STS | August 14, 2025 | November 14, 2025 |
An STS version can be a reasonable choice for a project under continuous development when its new features are required. It is less suitable for an organisation that expects to deploy a CMS and leave its major version unchanged for several years. Release lifecycle should therefore be part of the architecture and budgeting discussion—not an afterthought once security support ends.
Enhanced caching with HybridCache
One of the most important changes in Umbraco 15 was the new published-content caching strategy.
In earlier versions, NuCache eagerly loaded all published content into memory during application startup. This provided fast access after the cache was ready, but large content trees could increase startup time and memory consumption. Those costs became particularly visible on content-heavy platforms and in load-balanced environments.
The eager-loaded NuCache architecture used before Umbraco 15.
Umbraco 15 moved to a lazy-loading model. Content is loaded when it is needed instead of placing the complete content tree in memory immediately. Developers can use cache seeding to preload important content, such as the homepage, global settings or other frequently accessed nodes.
Umbraco 15 combines per-server memory caches with an optional distributed cache.
Microsoft HybridCache coordinates the in-memory cache and, when configured, a second-level distributed cache shared by multiple application instances. The new approach can provide:
- faster application startup;
- lower memory usage for large content repositories;
- more control over which content is preloaded;
- better support for distributed and load-balanced solutions;
- improved resilience when an application instance restarts.
The change is especially valuable for large websites, but it should still be tested against the real content tree and traffic profile. Cache seeding too much content can reduce the benefit of lazy loading, while seeding too little can move unnecessary work into the first user requests.
Block-level variants for multilingual websites
Managing multilingual pages becomes difficult when every language version has to maintain an independent block structure. Editors may need to reproduce the same layout repeatedly, and the structures can drift apart over time.
Block-level variants in Umbraco 15 allow a block editor to share its structure across cultures while selected property values vary by language. An editor can therefore translate or localise the content inside a block without rebuilding the entire page composition.
The same block structure edited in English and Danish using split view. Screenshot captured from the official Umbraco 15 demonstration.
When blocks are added, moved or removed, structural changes can be reflected across the language variants. This helps teams:
- keep regional websites structurally consistent;
- reduce repetitive work for editors;
- lower the risk of missing blocks in one language;
- preserve local control over text, media and other variant properties.
This model works particularly well for organisations that use a common global design with localised content. Projects in which each market requires a substantially different page structure should define their variation strategy carefully before changing existing document types.
Client credentials for secure integrations
Umbraco 15 added first-class client credentials support for machine-to-machine communication. Integrations no longer need to rely on a normal backoffice user’s interactive login or store that user’s password in a background service.
A dedicated API user in the Umbraco 15 backoffice.
API users can authenticate external systems against the Management API, while API members support server-to-server access to member-protected content through the Delivery API. Typical scenarios include synchronising content with another platform, running automated publishing workflows, importing product data or securely delivering protected content to another application.
This is a cleaner foundation for headless and composable architectures. Each integration can have its own identity and secret, making it easier to apply least-privilege permissions, rotate credentials and revoke one integration without affecting human users or other systems.
A new Rich Text Editor: Tiptap
Tiptap became the default Rich Text Editor in Umbraco 15. It replaced TinyMCE as the default UI because TinyMCE 6 had reached End-of-Life and the licence for TinyMCE 7 did not align with Umbraco’s open-source model.
For content editors, the experience remained intentionally familiar. For implementers, the new editor provided a modern configuration interface, a drag-and-drop toolbar and extension points for custom toolbar actions and media uploads. As an open-source, extensible editor framework, Tiptap also gave the Umbraco ecosystem a better base for future improvements.
Configuring the Tiptap toolbar and extensions in Umbraco 15. Screenshot captured from the official Umbraco 15 demonstration.
TinyMCE was still included in Umbraco 15 to make the transition easier. Nevertheless, projects with custom TinyMCE plugins, toolbar commands, styles or paste-processing rules need a proper compatibility review. Existing rich-text content may be reusable, but a custom editor integration cannot be assumed to work unchanged with Tiptap.
The modern backoffice matters when upgrading from Umbraco 13
For a project moving from Umbraco 14 to 15, many changes were evolutionary. For a project moving from Umbraco 13 or an older version, the larger consideration is the backoffice transformation introduced in version 14 and inherited by version 15.
The modern backoffice is based on TypeScript, Web Components, Lit and the Umbraco UI Library. It communicates through the Management API and replaces the old AngularJS-based extension model.
As a result, a migration from Umbraco 13 or earlier should include an audit of:
- custom property editors, dashboards, sections and tree extensions;
- AngularJS controllers, views and services;
- third-party packages and their supported Umbraco versions;
- custom backoffice API controllers and authentication flows;
- Rich Text Editor plugins and configuration;
- build, deployment and frontend tooling used by backoffice extensions.
Some extensions may only require an updated package. Others will need to be rebuilt against the modern Extension API and Management API. This work often has a greater influence on migration cost than the database upgrade itself.
Should you upgrade to Umbraco 15 today?
No new project or migration should target Umbraco 15 now that it is End-of-Life. An existing version 15 website should be upgraded to a supported release, with Umbraco 17 LTS being the usual long-term target at the time of writing.
Before choosing an upgrade path, we recommend checking:
- the current Umbraco and .NET versions;
- package compatibility and licence requirements;
- custom backoffice extensions;
- Rich Text Editor customisations;
- caching, cache seeding and load-balancing configuration;
- Management and Delivery API integrations;
- multilingual content and block-editor structures;
- automated tests, performance baselines and deployment procedures.
A short technical discovery phase makes the scope visible before development starts. It also helps separate components that can be upgraded from those that should be replaced or redesigned.
We can help you upgrade your Umbraco application
At CodeMasters Solutions, we have delivered commercial Umbraco projects and migrations from legacy versions such as Umbraco 6 and 7 to modern .NET-based releases.
We can help you with:
- an audit of your current Umbraco solution;
- package and custom-code compatibility analysis;
- a migration roadmap, risk assessment and estimate;
- rebuilding legacy backoffice extensions;
- content and data migration;
- automated testing, performance optimisation and deployment;
- post-migration support.
If your website runs on Umbraco 15—or another unsupported version—an upgrade is not only an opportunity to introduce new features. It is an important step towards keeping the platform secure, maintainable and ready for future development.
