Estimating a complex Umbraco upgrade project, especially from v7 all the way to 13, is a perilous duty. In many cases, there are simply cans of worms you don't even know about until you open the can they're inside of. Here's 10 things to watch out for, and explain to your stakeholders:
If your site is on Umbraco 7 and it uses nested content, you’re going to have a bad time.
Nested content usually needs to be re-created, line by line, and this can take a lot of time. Fortunately, it can be done by a junior content editor.
If you’ve used bulleted lists, it goes faster, but it’s still no small task.
Since Umbraco is an open-source CMS and architecturally follows a “framework” approach (in contrast to Drupal or Wordpress which are following a more modular or plugin based approach), it can easily be extended professionally by altering its source code or augmenting it with native c#/.net code.
If a website is heavily modified in this way, then it will most likely rely on platform- and version-specific code (i.e.: an Umbraco v7 website was extended by custom code built using .NET libraries), so an upgrade between a customised or extended Umbraco v7 to Umbraco v13 could potentially mean “porting” or modifying the custom code so the old .NET 4.5 libraries referenced are replaced by their new .NET 8 library counterparts.
Another potential issue: custom code written with earlier C# version (5.0 or 6.0) syntax, would need to be changed or converted to follow C# 12.0 language constraints.
Read more about the differences between .NET 4.5 and "New" .Net 8
The database structure has been adjusted to integrate new features, boost performance, and uphold data integrity. Enhancements encompass performance boosts through refined queries, optimized indexing, and efficient caching mechanisms.
Additionally, security measures have been fortified by enhancing encryption methods, implementing access controls, and addressing potential vulnerabilities. Updates also guarantee compatibility with the latest versions of database management systems like SQL Server or MySQL, aligning with evolving industry standards and best practices.
If your site is old and you have a few custom packages, modules someone built ages ago, or packages that are no longer supported, you’ll need to find alternatives.
This can sometimes push the cost out a bit, if you weren’t anticipating having to pay to replicate existing functionality.
If your site is old and runs a bunch of custom packages that aren’t supported any longer, you’ll need to find or build alternatives.
This can sometimes push the cost out quite a lot, if you weren’t budgeting for paid apps to replicate existing functionality.
The problem with the rest of the company is that it keeps asking you to build stuff on the website you’re trying to upgrade. Keeping up with (or saying no to) the constant flow of feature request, page updates, and bug fixes means that you will have far less time to work on the upgrade than you think.
Plan this into the upgrade project’s scope, and be militant about enforcing dev freezes and limiting non-upgrade story points in sprints.
Sometimes, when Marketing hears that you’re upgrading the website, they start to want things. Like features and functionality and maybe a new stylesheet and some different buttons, and a whole new cart cos it’s been a while...
Embarking on an upgrade project without making it clear to the rest of the business that dev resources will be limited means you’ll be constantly disappointing stakeholders.
Telegraph the upgrade period months in advance. Try to get as many requests queued up as possible, and manage expectations the best you can.
Hand in hand with the previous point is old stuff on your old site that is going to keep breaking, and is not allowed to be broken. You will need to stop work on the upgrade almost every sprint to fix something old before it can be replaced.
It’s frustrating, but it happens. Plan for it.
Getting Marketing folks (or whomever mostly uses the CMS to create pages apart from the Web team) to be part of the process is essential. Get them to test, show them previews, and get them excited about it.
Otherwise it’s just some techy thing that means they can’t publish landing pages.
An upgrade may be “free”. But it costs money and time. If you don’t have the time, you need someone else to do it for you, and that costs money.
Even if you’re doing it internally, it still creates an opportunity cost in the form of work not done, campaigns launched minimally, and frustrated users.
The only way to counter this is to secure management buy in and get the “funding” - whether that’s simply the political breathing space to carry out the upgrade, or the budget to hire an agency.
If you’d like some help making the case for why your Umbraco upgrade needs to be done right now, pop us a message on LinkedIn or on freshconstruct.com - we’re experts at presenting a compelling revenue-based case for keeping your CMS up to date
Then why not sign up for our newsletter! Keep up to date about the content your business needs to know.