Umbraco 13 vs 17: which LTS version to choose in 2026

If you are choosing between Umbraco 13 and Umbraco 17 in 2026, choose Umbraco 17. It is the current long-term support (LTS) release, runs on .NET 10 and receives security fixes until November 27, 2028. Umbraco 13 is already in its security-only phase, reaches end of life on December 14, 2026, and runs on .NET 8, which Microsoft stops supporting on November 10, 2026.

The real question for most teams is not which version is better but when and how to move existing Umbraco 13 sites. Below we compare the two LTS versions on support, runtime, back office and package ecosystem, look at the few cases where staying on 13 is still reasonable, and outline the upgrade path between them, with examples from our own projects and packages.

Umbraco 13 vs 17 at a glance

Dates come from Umbraco’s long-term support and end-of-life page and Microsoft’s .NET support policy.

Umbraco LTS and STS policy in short

Umbraco ships a major version roughly every six months. Each major has an active phase of about six months with minor releases every six weeks, then a support phase and a security-only phase:

• STS (standard-term support): support phase of 3 months, security phase of 3 months. Umbraco 14, 15, 16 and 18 are STS.
• LTS (long-term support): support phase of 18 months, security phase of 12 months. Umbraco 10, 13 and 17 are LTS.

Umbraco aligns LTS majors with .NET LTS releases. That is why 13 shipped on .NET 8 and 17 on .NET 10. The current schedule lists Umbraco 18 (released June 25, 2026) and 19 (planned December 10, 2026) as STS releases, and Umbraco 21 (planned December 9, 2027) as the next LTS. For teams that want few major upgrades, the rhythm is 13, then 17, then 21.

Support dates and what they mean in October 2026

Umbraco 13 has been receiving security fixes only since December 2025. Bug fixes are no longer shipped. From December 15, 2026 it receives nothing at all unless you buy Umbraco 13 XLTS, a paid extension that delivers security patches through a private NuGet feed for 6, 12 or 24 months, starting the day after end of life, with no gaps allowed.

The runtime is a separate concern. Umbraco 13 is based on .NET 8, and Microsoft’s support for .NET 8 ends on November 10, 2026. Umbraco’s XLTS page does not say how .NET 8 patches are handled after that date, so if you plan to rely on XLTS, ask Umbraco directly what it covers for the runtime.

Umbraco 17 has a full year of support phase left (to November 27, 2027) and a further year of security fixes after that.

Back-office differences

This is the change editors notice and the one that costs developers the most.

Umbraco 13 still uses the AngularJS back office that dates back to Umbraco 7. Custom dashboards, sections, content apps and property editors are AngularJS controllers and views registered through package.manifest files.

Umbraco 17 uses the back office introduced in Umbraco 14 (code name Bellissima). It is built on the Umbraco UI Library and Web Components, extensions are typically written in TypeScript with Lit, and almost every part of the interface is itself an extension. The old AngularJS code does not run in it. Umbraco 17 also lets the whole back office run across multiple servers behind a load balancer, which matters for large editorial teams (Umbraco noted this was not yet available on Umbraco Cloud at release).

Other differences editors and developers will meet:

• Blocks everywhere. Nested Content and the Grid Layout are gone; Block List and Block Grid replace them. Macros are gone; partial views and blocks in the rich text editor replace them.
• Tiptap instead of TinyMCE. Data types using TinyMCE are migrated to Tiptap on upgrade to 16 or later, unless you install a package that keeps TinyMCE.
• UTC dates. System dates are stored in UTC, with a migration that runs on upgrade and a new date-time picker that includes time zones.
• Caching. Umbraco 15 replaced NuCache with .NET HybridCache and lazy loading, and removed the published snapshot APIs.
• JSON. System.Text.Json replaced Newtonsoft.Json in 14, and UmbracoApiController output changed from PascalCase to camelCase.

Package ecosystem readiness

When Umbraco 14 shipped, many packages had not yet been rewritten for the new back office, and that was a fair reason to wait. By the 17 release Umbraco described the ecosystem as having caught up, and nearly a year later most actively maintained packages ship versions for 17 and 18. A few practical points:

• Check every package individually. Look at its NuGet dependency ranges, not just its marketing page. Packages that were not rewritten for the new back office will never run on 17.
• Umbraco Forms licensing changed. Forms 17 needs a license key in appsettings.json instead of a .lic file, and one-off licensing ends with Forms 17 in favor of subscriptions. Existing one-off licenses keep working on earlier versions. On Umbraco Cloud the Forms license is included.
• Some packages are 13-only by design. Our own OskiStarterKit is a good example: its 4.x line targets Umbraco 13 and .NET 8, with older lines for 9 to 12. It is a starting point for new sites, and on a new project in 2026 you would start on 17 instead.
• New packages are 17-first. Our AI packages umContentGenerator and umContentTranslator were released in 2026 for Umbraco 17 and 18 on .NET 10, with no Umbraco 13 version. That pattern is common: new extensions are built only for the new back office.

When staying on Umbraco 13 still makes sense

There are a few legitimate reasons to stay on 13 for a while:

1. The site is being retired or replaced within months and will not survive into 2027.
2. A rebuild is already scheduled, and upgrading the old code now would be thrown away.
3. You need time and can pay for it. XLTS buys 6 to 24 months of security patches while you migrate, without new features.
4. A critical package has no 17 version yet and replacing it needs budget you do not have this quarter. This is a reason to plan the replacement, not to stay indefinitely.

What is not a good reason: waiting for the ecosystem to mature, or waiting for a later version. Umbraco 18 and 19 are short-term releases. Umbraco 21, the next LTS, is planned for December 2027, a year after 13 reaches end of life.

Upgrade path from 13 to 17

Umbraco’s upgrade documentation says you upgrade to the closest LTS major, and for 13 that is 17. You do not install 14, 15 and 16 along the way, but every breaking change in those versions still applies to your code. Umbraco describes two routes:

• Direct upgrade. Update the NuGet packages and target framework in the existing solution, run the database migrations, then fix what breaks. Lower initial effort, more continuity, and technical debt comes along.
• Rebuild and migrate. Create a fresh Umbraco 17 solution and move content and schema with Umbraco Deploy import, which can transform legacy data during import. More planning, more room to clean up. Umbraco’s own article says that for most cases it makes more sense to build fresh on 17.

A typical direct upgrade checklist:

• Update to the latest Umbraco 13 minor and take a database backup
• Convert Nested Content to Block List and Grid to Block Grid while still on 13 (Umbraco Deploy migrators or a community tool)
• Replace macros with partial views or rich text blocks
• Change the target framework to net10.0 and update Umbraco packages to 17
• Fix compile errors from the cache, JSON and API changes
• Rebuild every AngularJS back-office extension as a Web Component extension
• Rebuild Models Builder models and review date handling after the UTC migration
• Test on a copy of production data, then rehearse the cutover

The project file change itself is small (illustrative):

<!-- Illustrative: core change in the web project's .csproj -->
<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Umbraco.Cms" Version="17.*" />
</ItemGroup>

Everything around it is where the time goes. In practice the effort concentrates in custom back-office code, removed editors and package replacements, which is also what we saw when moving the Jongeneel platform all the way from Umbraco 8 to 17 on .NET 10: the plugins, background jobs and one deprecated package (NuPicker, replaced with Contentment) needed most of the attention, not the content.

What about sites on 14, 15 or 16?

STS versions have short lives. Umbraco 14 and 15 reached end of life in 2025 and Umbraco 16 on June 12, 2026. Sites on these versions already have the new back office, so moving to 17 is usually much smaller than coming from 13.

We built the third generation of Auto.co.il on Umbraco 15 and .NET 9: about 100,000 content items imported from a legacy CRM, Lucene search with custom caching over Umbraco’s hybrid cache, and front-end components written in Lit with TypeScript. Because it already runs on the Bellissima back office and HybridCache, a site built this way has far less to rewrite on the way to 17 than a 13 site with AngularJS extensions. The general rule: if you build on an STS release, budget for a move to the next LTS within months.

Decision table

Bottom line

Umbraco 13 served well, but its window is closing on two fronts at once: the CMS in December 2026 and .NET 8 in November 2026. Umbraco 17 on .NET 10 gives you a supported stack to late 2028 and a back office that new packages are built for. Start the inventory now: packages, back-office extensions, removed editors and integrations. If you want a second opinion on the estimate, our Umbraco development team runs 13 to 17 upgrades and longer migrations.