Umbraco 19 is a Standard-term Support (STS) release, the second since the Umbraco 17 Long-term Support (LTS) release. Umbraco 17 is supported until November 2028, and Umbraco 21 is planned as the next LTS in December 2027. So staying on 17 and waiting for 21 is a perfectly reasonable choice.
If you're weighing it up, though, I'd encourage you to take a look at 19. You can upgrade to Umbraco 19 directly from 17 without stopping at 18.
Moving off an LTS onto the STS releases was a large jump from Umbraco 13, which brought in the new backoffice and a substantial rework for anyone with custom backoffice extensions. That's not what the current STS cycle is about. The backoffice and most APIs you know from 14 through 18 are what you'll find in 19, and for many projects the upgrade will be fairly routine.
Your developers and editors get the new features a year or so earlier than waiting for 21. And rather than taking on the changes from 18, 19 and 20 in one go, you can deal with them in smaller steps. The trade-off is a shorter support window - Umbraco 19 is supported until December 2027 - so you'd be committing to keep moving with the releases until 21 arrives.
It is a major version, though, and there are breaking changes. The one most likely to affect you is search, which I'll cover further down. If you're coming from 17, please make sure to read the upgrade notes for 18 as well.
Umbraco 19 runs on .NET 11, Microsoft's newest release, due out this month and currently itself a release candidate. You'll need it installed wherever you run Umbraco 19, and projects need to target net11.0.
This continues a pattern: each of our winter majors ships on the .NET version Microsoft releases that November - Umbraco 15 on .NET 9, 17 on .NET 10, and now 19 on .NET 11. Our LTS releases also align with .NET LTS versions, so Umbraco 21 will follow suit with .NET 12.
This means you get the benefits of each .NET release with Umbraco. Each one brings performance improvements, which come for free with the upgrade, with no changes to your own code.
We've also opted in to .NET 11's runtime async, where the runtime itself, rather than the compiler, handles async methods. It's planned as the default from .NET 12, but is currently new and optional, which is partly why we wanted it in place for the beta and RC. This applies to how Umbraco itself is compiled - your own projects don't need to opt in. We don't anticipate problems, but if you see anything unexpected that might be related, please let us know.
In the Umbraco 18 RC post, I described Elements and the Library section as phase one of a larger feature, with the bigger payoff for editors coming in Umbraco 19. I'm pleased to say that it has now arrived.
Library Elements can now be inserted as blocks in the Block List, Block Grid, Single Block and Rich Text editors, via a new Library tab in the block picker. When you publish changes to the Element in the Library, every page using it is updated.
It works the other way round too: a block can be transferred to the Library to make it reusable, provided its Element Type is allowed in the Library. And if an editor needs a page-specific variation of shared content, they can disconnect a block from the Library, creating an independent local copy without touching the original.
As shared content has a wider impact, we've made it clear what's shared and what isn't. Blocks referencing Library content are visually distinguished, and flag when the referenced Element is unpublished, has unpublished changes, or has been trashed. When you publish an Element, you're told how many items reference it. And when you publish a page using Library Elements that are unpublished or have pending changes, you're warned before it goes live.
The Elements documentation covers setting up Element Types for the Library, and there's a dedicated article on reusable content in block editors.
Alongside Umbraco 17, we introduced a new search abstraction as a separate add-on package, Umbraco Search, for Umbraco 17 and 18. In Umbraco 19 it moves into core and becomes the single search layer for the backoffice, the Delivery API and your templates.
Examine is still there, upgraded to version 4 and shipped as the default provider with nothing extra to install. The difference is that it's now a provider, rather than something the rest of Umbraco depends on directly. Plug in a different search engine, and the backoffice, Delivery API and website will all use it, as will any of your own code written against the abstraction.
For querying, the main entry point is ISearcher, supporting full-text queries, filters, facets, sorting, pagination, culture and segment targeting, and protected content. The search getting started guide walks through it with examples.
Other improvements that come with this:
More content is searchable. Library Elements have their own index, language-specific block content is indexed, and you can opt in to including reusable content from blocks in your site search, kept up to date as the shared Elements change.
Search inside files. An opt-in package indexes the text inside PDF, Markdown and text files used in content and media. It replaces the UmbracoExamine.PDF package.
Improved index management. The new Search item in the Settings section is an improved successor to the Examine Management dashboard, for inspecting, searching and rebuilding your indexes, whichever search provider you use.
Many Umbraco sites are multilingual, and more and more also personalize content for different visitors. Umbraco 19 improves variants for both.
For multilingual sites, a new user group permission controls who can edit content shared across all languages, replacing the previous site-wide setting. Language access, which already limits which languages editors can save and publish, now also applies to Elements in the Library.
For personalization, we've reworked the segment model. A segment has only ever really been an optional override of a property's default value, but parts of the model suggested it could stand on its own, with its own name and publish state. In Umbraco 19, the model reflects how segments actually work: segment values belong to their language, so publishing the Danish version of a page publishes its segment values with it, and which blocks are on a page is managed per language rather than per segment.
Building on that, Element Types - for Library Elements and for blocks - can now vary by segment, so a block's properties can hold different values per segment. Validation also now covers segment values when publishing, including when publishing from the tree without saving first.
Finally, the segment options shown in the editor now come from an extension point, so a package can supply its own segments or replace the built-in ones.
Together, these changes give Umbraco Engage what it needs to personalize content at the block level - showing different block content to different visitor segments, without editors copying an entire page to change one block. The Engage team are working towards this, so look out for news from them on when it will be available.
Document Blueprints - pre-filled starting points for new pages - have up to now lived awkwardly in the Settings section, which many editors can't see. In Umbraco 19 they move to the Library, alongside the other reusable content. Blueprint start nodes on user groups and users now control which Blueprints people can access, and you can choose a folder when creating a Blueprint from a page.
This one has caught out plenty of Umbraco developers over the years. Several built-in property editors returned a different model depending on their Data Type configuration. Tick a media picker's "pick multiple items", or raise a URL picker's maximum items from one to two, and the property switches from returning a single item to a collection. An innocent-looking backoffice change could break templates and Delivery API consumers at runtime, without warning.
In Umbraco 19, the model a property returns depends only on its property editor, not its configuration. Editors that used to vary have been split in two, each with a fixed model:
Media picker - the existing editor returns a collection, and a new single media picker returns one item.
URL picker - likewise, the existing multi URL picker returns a collection, and there's a new single URL picker.
Dropdown - a new single-choice dropdown alongside the existing multiple-choice one.
Slider - a new range slider, returning a range, alongside the existing single-value slider.
Label - new labels for each value type (text, integer, big integer, decimal, date and time, and time), each returning that type.
Document and member pickers - new multiple document and multiple member pickers alongside the existing single ones.
It's the same approach we took in Umbraco 18, when single block mode moved out of the Block List into its own Single Block editor.
On upgrade, migrations move existing Data Types onto the right editor based on their configuration - a media picker set to pick a single item becomes a single media picker. Stored content doesn't change, and nor does the shape of the Delivery API output.
The Multi Node Tree Picker is the clearest example of the problem: it could pick documents, media or members, one or many, all from one editor. With the new multiple document and member pickers, a member type filter on both member pickers and dynamic root support on the document picker, the dedicated pickers now cover everything it could do.
So in Umbraco 19 the Multi Node Tree Picker is deprecated. Existing properties using it keep working, but it's no longer offered when creating new Data Types. It will be kept available until at least Umbraco 22.
Cookie-based backoffice login. The backoffice now uses a standard secure session cookie instead of OAuth access and refresh tokens. Sessions are renewed while you're active, two-factor authentication works with external login providers, and preview and trashed media use the same login as the rest of the backoffice.
ImageSharp 4 is now the default for image cropping and resizing, though sites can stay on ImageSharp 2. There's no longer an ImageSharp 3 option.
As always, the version-specific upgrade documentation is the page to bookmark, with the full list of breaking changes and preparation steps. The general upgrade guide covers the process itself. Here are the changes most likely to need your attention.
If your site or package uses search, this is where most of your upgrade effort will likely go.
A good first port of call here is the blog of my colleague Kenn Jacobsen, where he has published an in-depth migration article for Search.
The Examine integration replaced by Umbraco Search section of the breaking changes also has the detail, and the search documentation shows how to use the new APIs.
It's also worth mentioning that if you are already heavily invested in Examine, and have no expectation of implementing a different search provider for your project, the direct Examine 4 APIs are available and will continue to work. You can use them on upgrades with some tweaks. Again Kenn has covered this in a recent blog post.
With cookie-based authentication, the token methods - getLatestToken() and similar - are removed, so backoffice extensions that use them will no longer compile. The fix is to remove the token handling and send requests with the browser cookie instead, using credentials: 'include'. If your package makes custom API calls from the backoffice, test it against the RC.
Smaller changes worth checking against your project:
Back up your database before you start. Once upgraded, Umbraco 18 can't open the database, so restoring the backup is the only way back.
Imaging HMAC secret key. Due to stricter Base64 decoding in .NET 11, the key must be valid canonical Base64, or the site won't start. Keys generated by Umbraco are fine, but a hand-entered one may not be. The documentation explains how to fix this while keeping existing signed image URLs working.
Database command timeout no longer falls back to the connect timeout, and uses the provider default of 30 seconds unless set explicitly.
Property editors. Check code reading values from media pickers, URL pickers, dropdowns, sliders and labels that the migrations move onto a new editor. Data Types moved to a single-item editor lose their item-count settings, so if a minimum of one item made a property required, make the property mandatory instead. A multi URL picker no longer silently drops links over its maximum, so a property over its limit will start rendering the extra links. Take care with Umbraco Deploy or uSync artifacts exported before the upgrade, as importing them may move migrated Data Types back to their old property editors.
Shared content permission. The upgrade grants the new permission to existing user groups to match their current access, but new user groups start without it, so grant it where needed.
Configuration. The Debug section moves to Umbraco:CMS:Debug, some settings are removed, and image-processing memory limits and clock-aligned scheduled publishing are now on by default.
Obsolete code removed. Most code marked for removal in 19 is gone, so resolve any obsolete warnings before upgrading. Most warnings name the alternative to use.
API changes. A few Management API endpoints are removed, user group requests have a new required field for the shared content permission, and Delivery API operation IDs change from 2.0 to 2_0, so generated clients need regenerating.
These are the changes most likely to affect you, not the complete picture. Before you upgrade, please read the full set of breaking changes for Umbraco 19, which details every change and what to do about it. If you're coming from Umbraco 17, review the breaking changes for Umbraco 18 too.
Between now and the 10th of December, we'd really value your help testing the RC against real projects, packages and websites - particularly upgrades involving custom search code and backoffice extensions, where the larger changes are.
If you find anything, after a quick check that it's not already reported, please raise it in the CMS tracker, noting the version you found it in.
You'll find the release candidate on NuGet and release details on GitHub and releases.umbraco.com.
And, as always, thank you to everyone who has contributed code, ideas, bug reports and conversations to this release.
If you've talked to anyone from Umbraco HQ lately, you've probably heard us say we're building the most agent-ready CMS out there. That's not a slogan, we mean it literally: with the Umbraco CMS Editor MCP now in beta, and a growing family of Developer MCPs and Skills following for Automate, Engage, and Forms, your editors, developers, and your AI agents can all work smarter directly in and outside Umbraco.