If you skipped Umbraco 14, 15, and 16 (and many orgs did) because v13 was the Long Term Support (LTS), a v13 to v17 upgrade is not a bump. It's a catch-up. Three major releases worth of architectural change happened, and the upgrade you scope needs to account for all of them. Underestimating that is the single most common reason a "we'll do it in a sprint" project ends up taking months.
Here's what actually changed in the middle, and why it matters.
Version 14: The backoffice was rewritten from scratch
The headline change in v14 is the foundation. The entire admin interface was torn out and rebuilt from the ground up. AngularJS is gone, replaced with TypeScript, Lit, and Web Components, with a build chain on Vite. That means a backoffice with a new architecture, a purpose-built Extension API, and a corresponding Management API.
The architectural shift sounds clean, but for v13 shops it has one very specific consequence: every custom backoffice extension has to be rebuilt — custom property editors, dashboards, sections, trees. Anything you wrote against the AngularJS APIs no longer has a home. The Umbraco 13 backoffice was tightly coupled to AngularJS. Starting with version 14, the backoffice is framework-agnostic, and the only requirement is that extensions are built as Web Components using Lit.
There's a silver lining. The new model is genuinely more flexible, and you don't have to learn Lit if you don't want to. The constraint is "must compile to a Web Component," not "must use a specific framework."
Action item for scoping: Inventory every custom backoffice extension in your project. That list, multiplied by the per-extension rewrite estimate, is a key number in your upgrade plan.
Version 15: A new content cache and a new rich-text editor
While version 14 rewired the editor UI, version 15 rewired what happens behind it.
The biggest under-the-hood change is the content cache. Per the official v15 release blog, "one of the biggest changes is the shift from an eager content cache to a more efficient lazy-loaded content cache, where primary content is preloaded at startup and secondary content is fetched as needed, reducing memory strain and keeping sites fast." For very large sites, this changed memory profile is one reason v17 sites behave better than equivalently-spec'd v13 sites.
The same release introduced Tiptap as a rich-text editor option (it ships alongside TinyMCE in v15 — that becomes important in v16). It also brought block-level variants for multilingual editing, and API Client Credentials for secure machine-to-machine integrations, which is a meaningful step up if you're driving the Delivery API from a partner system.
Action item for scoping: If your site is large, plan to performance-test in a staging environment after migration. The lazy-cache improvements will help most workloads but may surface new behaviors if you have unusual content access patterns.
Version 16: Tiptap becomes the default, TinyMCE is gone
Version 16 is where editorial workflow changes the most, and where the migration starts touching your content. Tiptap had been an option since v15. In v16, it became the only rich-text editor shipping in the box.
The reason is licensing, not engineering preference. TinyMCE's license change prevents shipping it with the MIT-licensed Umbraco CMS. The v16 release candidate blog covers it from the official side.
For v13 organizations upgrading straight to v17, this is the change that touches content, not just code. Umbraco automatically migrates existing rich-text-editor (RTE) content to Tiptap as part of its standard migration, with existing content remaining intact, but datatypes need review. In practice, most content migrates fine, but expect to do a content audit on richer pages. Anything with embedded macros, custom inline blocks, or unusual formatting deserves a manual review. If you have structural/presentation markup (e.g. divs with style classes) in your content, you’ll likely need to account for that when scoping the upgrade. v16 also introduced property-level permissions and content segments, both of which are useful but can ripple through your editorial governance model if you take advantage of them.
Action item for scoping: Budget a content QA pass after the upgrade, and decide upfront whether you're staying on Tiptap (recommended) or paying to bring TinyMCE back in.
Version 17 brings its own additions on top
Once the catch-up is done, v17 adds its own layer, the load-balanced backoffice, .NET 10, UTC date handling, and the new search abstraction, all covered in the second post of this series.
The honest takeaway: A v13 to v17 upgrade is three releases worth of work compressed into one project. That's not a reason to delay. It is a reason to scope correctly. Teams that plan for the backoffice rewrite, the content cache shift, and the RTE migration up front will have a much better time scoping. The teams that treat it as a package bump tend to discover the iceberg in week three.
If you're planning an Umbraco 13 to 17 upgrade and want a clearer picture of what the work actually involves, [A] can help you assess the path, identify the risky parts early, and build a realistic upgrade plan.