We recently shared what we learned upgrading a large Umbraco project from version 13 to 17. But before that, we've also taken projects through another significant Umbraco migration: Umbraco 8 to Umbraco 13. You can see how we approached one of those migrations in our Umbraco 8 to 13 case study.
Moving from 13 to 17 involves plenty of breaking changes, migrations and redevelopment, but you're still working within broadly the same modern .NET world. Moving from Umbraco 8 is different.
The move away from .NET Framework means an Umbraco 8 → 13 migration isn't simply about upgrading Umbraco. You're crossing a major change in the underlying technology as well. That raises an important question for anyone maintaining an older Umbraco website:
Should you upgrade the existing site at all, or use the opportunity to rebuild it on the latest version of Umbraco?
Why Umbraco 8 → 13 is such a big jump
Umbraco 8 applications were built on ASP.NET and the .NET Framework, while later versions of Umbraco moved onto modern .NET. That change has consequences throughout an application. Code written around the old Umbraco and ASP.NET APIs often can't simply be carried across. Depending on the project, you may need to revisit:
Application startup and configuration
Dependency injection
Controllers
Routing
Services and repositories
Authentication
Configuration files
Custom middleware and HTTP handling
Umbraco APIs
Models
Property editors
Backoffice extensions
Third-party packages
Build and deployment processes
Suddenly, what sounds like an Umbraco upgrade starts looking much more like application redevelopment.
Your content needs migrating too
Code is only half of the problem. A mature Umbraco 8 website may contain years of content built around document types, data types, property editors, macros and packages that have changed significantly in newer versions. Some structures can be migrated relatively cleanly. Others need transformation.
And custom functionality makes things more interesting again. An old property editor might rely on AngularJS. A package might no longer exist. A macro might need replacing with a component. Content might depend on a data structure that no longer makes sense in modern Umbraco. So before starting, it's important to understand not only how much code you have, but how dependent your content is on the old implementation.
Third-party packages can determine the difficulty
Packages are one of the first things we'd audit. For every package in the existing application, we'd ask:
Is there a supported equivalent for the target Umbraco version?
If there is, great, although you'll still need to understand its migration path. If there isn't, you have another decision to make:
Replace it with another package
Replace it with native Umbraco functionality
Rebuild the functionality yourself
Remove it entirely
Multiply that across a website that's been developed and extended for several years and the scope can grow quickly.
Don't rebuild technical debt just because it already exists
This is perhaps the most important lesson we've taken from these migrations. When upgrading an old application, there's a temptation to reproduce everything exactly as it exists today. But should you?
Imagine an Umbraco 8 project has a custom property editor created six years ago to solve a particular backoffice problem. You could spend time understanding it, rewriting it for modern Umbraco, migrating its data and testing the new implementation. But perhaps modern Umbraco already provides a better solution. Or perhaps nobody actually uses the feature anymore. A major migration is a good opportunity to ask:
If we were building this website today, would we build this feature the same way?
Quite often, the answer is no.
So why not go straight to Umbraco 17?
This is where the decision becomes particularly interesting today. If you're still running an Umbraco 8 website, upgrading it to another intermediate version may not necessarily represent the best investment. You're already facing substantial redevelopment because of the framework change. So rather than asking:
How do we get this Umbraco 8 website onto a newer version?
It may be more useful to ask:
What is the best way to get this organisation onto a modern, maintainable Umbraco platform?
Those aren't quite the same question. For some projects, migrating the existing application remains the right answer. For others, building a new site directly on Umbraco 17 and migrating the valuable content across may be more sensible.
When upgrading the existing site makes sense
An upgrade can still be attractive when the existing website is fundamentally in good shape. Perhaps:
The frontend is still performing well
The design doesn't need changing
The information architecture remains appropriate
Content structures are sensible
There isn't excessive custom functionality
Most dependencies have clear migration paths
The site contains complex functionality that would be expensive to recreate
The organisation simply wants to modernise the underlying platform
In that situation, preserving the existing application can avoid rebuilding functionality that already works. The important thing is to establish how much of it can genuinely be preserved.
When a rebuild starts looking more attractive
Now consider a different Umbraco 8 project. The design is showing its age. The frontend was written years ago. There are lots of custom property editors and abandoned packages. Document types reflect an old information architecture. Editors have accumulated workarounds for limitations that no longer exist. Performance needs attention. Accessibility needs improving. The organisation wants significant new functionality anyway. And a large proportion of the backend code needs rewriting because of the move away from .NET Framework.
At that point, spending a substantial budget recreating the old website exactly as it was can be difficult to justify. You may finish with a modern version of Umbraco underneath, but still have essentially the same old website sitting on top of it. A rebuild gives you the opportunity to start with Umbraco 17, modern .NET and current development practices while selectively migrating the content and functionality that still has value.
Upgrade vs rebuild isn't an all-or-nothing decision
There's also a middle ground. A rebuild doesn't necessarily mean throwing everything away. You might retain:
Existing content
Media
URLs and redirects
SEO metadata
Business rules
Integrations
Proven frontend components
Parts of the existing information architecture
while replacing the technical implementation underneath.
Content migration scripts can transform old content structures into new ones rather than requiring editors to manually recreate everything. This can sometimes be a better way to think about the project:
preserve the valuable parts, rather than preserving the application.
How we'd assess an Umbraco 8 site today
Before estimating an Umbraco 8 migration, we'd carry out a technical discovery rather than immediately committing to either an upgrade or rebuild. We'd want to understand:
Content — How much exists and how complex are the content structures?
Custom code — How much relies on APIs or frameworks that need rewriting?
Packages — Which dependencies still have supported modern equivalents?
Backoffice customisation — How many custom editors and extensions exist?
Frontend — Is the existing frontend worth preserving?
Integrations — What external systems does the website communicate with?
SEO — Which URLs, metadata and search performance need protecting?
Editorial experience — Are editors happy with the current site or are there longstanding pain points?
Accessibility and performance — Would preserving the existing frontend also preserve existing problems?
Future requirements — Is significant redevelopment already planned?
Only after understanding those areas would we compare the cost and risk of migration against rebuilding.
The surprising thing about a rebuild
"Rebuild" naturally sounds like the more expensive option. Sometimes it is. But when enough of the existing application needs rewriting anyway, the difference can become much smaller than expected. An upgrade can contain a lot of hidden effort:
understand old implementation → work out modern equivalent → rewrite it → preserve compatibility → migrate data → regression test old behaviour.
A rebuild can sometimes simplify that:
understand the requirement → build the appropriate modern solution → migrate the data that matters.
You're no longer constrained by reproducing historical technical decisions. That doesn't automatically make rebuilding cheaper. But it does mean the assumption that an upgrade must be cheaper than a rebuild is worth challenging.
What we've learned
Having worked through both Umbraco 8 to 13 migrations and more recent Umbraco 13 to 17 upgrades, one thing has become clear:
The version numbers alone don't tell you how difficult an upgrade will be.
The history of the individual website matters much more. An Umbraco 8 website with straightforward content and minimal customisation could be a relatively manageable migration.
Another Umbraco 8 website might contain years of custom development, obsolete packages and tightly coupled content structures. Those are completely different projects despite starting and finishing on the same Umbraco versions. And that's why, for an older Umbraco implementation, we'd recommend starting with a question rather than an upgrade plan:
What is actually worth keeping?
Once you know the answer, you can make a much better decision about whether to migrate the existing application or build something new on Umbraco 17.
Sometimes the best upgrade is a rebuild.