It's not about the content!
Umbraco HQ has a whitepaper out called "Don't just upgrade, evolve." It lays out two paths from 13 to 17, leans hard towards rebuilding fresh, and lands on Umbraco Cloud and a time-limited bundle. It is a good piece of marketing. It is also, like all vendor marketing, quiet about the one question that actually decides your project.
The question is not "should we upgrade or rebuild." It is "how much of your solution lives in the backoffice." Get that answer and the path chooses itself.
The content was never the hard part
Let me clear something up, because the HQ framing nudges you towards thinking content migration is the obstacle. It is not.
A direct 13 LTS to 17 LTS upgrade is supported now. There is no need to chain through 14, 15 and 16. The route is to get your site onto the latest v13 first so every v13-level migration is already applied, move it to .NET 10, then run the upgrade.
Umbraco's own migrations handle the database: content, schema, the lot. There is real change in there. Dates are now stored in UTC with a migration to align existing values, and the rich text editor changes from TinyMCE to TipTap, which converts your existing rich-text content automatically.
But none of that is the thing that sinks a project.
What sinks projects is custom code. And the single biggest piece of custom code in most mature Umbraco solutions is the backoffice.
What v14 actually broke
Umbraco 14 replaced the entire backoffice. The old AngularJS UI is gone. The new one is built on Web Components and the Umbraco UI library, with a completely different extension model. That is the real reason a 13 to 17 move feels like more than a version bump, not because content is hard to move, but because anything custom built into the editor experience needs rebuilding.
If your site has any of the following, there is backoffice work ahead regardless of which path you take:
Custom property editors written against the AngularJS API
Custom dashboards, sections, or context apps
Angular controllers, directives, or views bolted into the backoffice
Packages that shipped their own backoffice UI and have not been updated for v14+
That last one catches people out. Everything else can be in good shape and the project still stalls on a dependency that never made the jump.
So before committing to a path, the package list needs auditing against v17 compatibility. That audit, not the content, is the real risk register, and it is the first thing we run on any site we are asked to move.
So which path
Here is the honest framework, stripped of the vendor preference.
Path 1, upgrade in place, is the right call when the site is healthy and the custom backoffice surface is small. A well-built v13 site with a handful of standard property editors, clean templates, sensible models and current packages will go straight to 17 with less drama than the whitepaper implies.
The work is moving to .NET 10, rebuilding any backoffice extensions on the new model, working through the RTE and UTC changes, then testing and going live. Continuity is high and you keep your history.
Do not let anyone push you towards a full rebuild just because it sells better.
Path 2, fresh build on 17 plus Deploy import/export, earns its keep when the site has accumulated genuine debt, a backoffice stuffed with legacy custom editors, content types that grew organically over the years, structures no one would design that way today.
In that situation the backoffice work is being rebuilt anyway, so it makes sense to rebuild on a clean foundation and move the content across deliberately rather than dragging the clutter with it.
This is where Umbraco Deploy earns its place, and I want to be precise about why. The upgrade itself already handles version-to-version migration. Deploy's import/export adds a controlled way to move content and structure into a fresh instance, including custom migrators for project-specific data. That is the part that is hard to do by hand: reshaping a messy legacy model into something clean as it lands in the new site.
It is not magic and it does not rebuild the site for you. But for transforming old data structures it is the right tool, and we use it rather than hand-rolling that work.
Where I've landed on Cloud
I will be straight about my position, because I am an Umbraco partner and you should weigh that. I now default clients where possible to Umbraco Cloud, and a major upgrade is the moment I make the case hardest.
The reasoning is not romantic. A 13 to 17 move already forces a fresh look at hosting, deployment, environments and the whole operational picture. If that is being opened up anyway, doing it on a platform where hosting, environments and Deploy come as one managed thing removes a category of risk that otherwise sits with you.
Deploy is included with every Cloud plan, which matters a lot on Path 2. You get proper, repeatable environment promotion instead of a bespoke pipeline that someone set up years ago and no one wants to touch. And when a migration throws something odd at 11pm, there is a real support team behind the platform rather than a forum thread and a prayer.
The honest trade-off is cost and control. Cloud is a recurring spend and you give up some infrastructure freedom. If you genuinely need bare-metal control, or have hard data-residency constraints Cloud cannot meet, self-hosting still wins and I will say so.
For most sites, and that is most of the professional-services and legal clients we work with, the maths now favours Cloud.
The bit with an actual deadline
None of this is theoretical, because Umbraco 13 reaches end of life on 14 December 2026. After that date, no more patches, including security patches. As I write this in June 2026, that is roughly six months away, which for a move of this size is less runway than it sounds.
If you genuinely cannot make the date, Extended Long-Term Support exists, offering 6, 12 or 24 months of continued security and compliance coverage on v13.
Treat it as what it is: a paid bridge to buy planning time, not a strategy. Every month on XLTS is a month spent deferring the work rather than avoiding it. It is also not cheap.
The actual takeaway
The whitepaper's slogan is right for the wrong reason. This is a chance to evolve, not because content migration is scary, but because the v14 backoffice rewrite means your custom code gets touched no matter what. That is the moment to decide honestly whether the current build deserves to be carried forward or quietly retired.
It starts with an honest audit of the packages and backoffice customisations. That tells you the path. From there it is latest v13, then a direct move to 17. The one thing that matters most is starting now, because December is closer than it looks, and the sites that move calmly will be the ones that began planning in the first half of the year.
If your site is still on Umbraco 13 and you want a straight answer on which path fits, that is exactly the kind of assessment we do. No hard sell, just an honest read on what your site needs and what it will take.
