Skip to main content

How to upgrade a Umbraco v4 website to the latest version of v7

Why upgrade to v7?

A few months ago, I was asked to work on upgrading a Umbraco v4 (4.5.1) project to the latest version of v7 (7.15.10). 

My first reaction was to question the requirement as v7 is fast approaching its End of Life, in the end, I realised that the client simply didn't have the budget for a v10 upgrade, hence, my colleagues and I started working on a solid plan as this was still a big upgrade. 

Solid plan

When we did our research to see if anybody had written anything about the upgrade path from v4 to v7, we didn't find much except this good blog post. This was a very old article, but the explanation made sense. So, we decided to follow a similar approach. 

We created a new feature branch, and for each upgrade work, we created a new branch of this feature branch and then created PRs from those upgrade branches into this feature branch. After doing the code reviews, we merged each upgrade branch into this same feature branch.

After going live, we merged this "parent" feature branch into develop and main.

In terms of database upgrades, we used a copy of the live database for the dev upgrades. Once the upgrades were complete, we did our deployments to our testing environments, and simply restored the testing environments' databases from our dev database. Once the tests were complete, we did a deployment to our Pre-live environment and restored the Pre-live database from the dev database again. We then let the client create some additional content on the Pre-live website and when things were ready, we did a deployment to live and restored the live database from the Pre-live database. 

With its approach, we eliminated all the big risks for the database upgrades. This saved us a lot of time as well as possible headaches. (I just couldn't see another approach as this was still a big upgrade and database upgrades were potentially very problematic otherwise.)

Upgrade from v4.5.1 to v4.5.2

It is more difficult to do the very old Umbraco upgrades as there are no NuGet packages but DLLs and zip folders. Luckily, Lee Kelleher has this website that he uses to keep old Umbraco Archive Releases. We downloaded the zip files and did a minor upgrade to see if things were still looking good, and it worked!

Upgrade from v4.5.2 to v4.6.1

We followed the same manual approach until we had our first Umbraco NuGet package. At every step, we made sure we created back-ups. 



 









First Umbraco NuGet package and upgrade from v4.6.1 to v4.7.2

Our aim was to start using NuGet packages as soon as possible and v4.7.2 was the first available NuGet package. After our first NuGet package installation, we got rid of all the lib/Umbraco DLLs.

Following v4 upgrades

Following upgrades were v4.7.2 to v4.8.1, v4.8.1 to v4.9.0, v4.9.0 to v4.11.10. 

Each time we used NuGet packages, did our tests and code reviews, merged our changes into our feature branch, and carried on with a new feature branch off the main feature branch. 

Upgrade from v4.11.10 to v6.0.0

As you might know, Umbraco v5 had a lot of issues, hence Umbraco simply abandoned this version. As a result, the next step was to upgrade to the first version of v6. In order to keep things less risky, we first moved our project to 6.0.0.

Upgrade from v6.0.0 to v6.2.6

The next step was to upgrade to v6.2.6. After this point, it was time for v7.

Upgrade to v7.3.8

v7.3.8 was our first v7 version after v6.2.6. We continued doing our tests and fixed some minor issues. 

Following v7 upgrades

The following upgrades were v7.3.8 to v7.4.4, v7.4.4 to v7.5.15, v7.5.15 to v7.6.0 and v7.6.0 to v7.7.0. We did our package upgrades as normal and tried not to change anything else as much as possible. 

Finally v7.15.10 upgrade

The final step was to upgrade from v7.7.0 to v7.15.10 as we didn't see any big risk for this. After fixing a few WebForms-related errors, things were finally ready for the QA tests. 











QA Tests and live deployment

After the tests were complete, we did a deployment to Pre-live for the client to do their final tests as well as their additional content creation. 

Once they were done, we deployed the latest code to live and restored the live database from a Pre-live database backup. This way, we didn't have to worry about the live database upgrades!

After the live deployment, we saw the following error on one of the live website instances and fixed it with this small connection string change










Final thoughts

It was a nice experience to lead this Umbraco upgrade project. 

We didn't experience any big problems with our approach, this was due to our solid plan and great Development Team. 

As there are quite a few Umbraco v4 projects lying around, and there aren't a lot of articles about how to upgrade these old Umbraco projects, hopefully, this article will be helpful to some others. 











Comments

Popular posts from this blog

How to fix Umbraco v9 "Boot Failed : Umbraco failed to boot, if you are the owner of the website please see the log file for more details." error

If you have started working with Umbraco v9 and done your first Azure deployment to one of your testing environments, there is a possibility that you might see the following "Boot Failed" error. Error: Checking the logs In order to understand the problem, you should check the Umbarco log file.  The default location for this file is umbraco/Logs and this file contains the Machine name, along with the date information. You can reach this file via Azure's Kudu Service  or alternatively, you can get download your Azure App Service's publish profile and connect your App Service via an FTP application, i.e. FileZilla. See the FileZilla screen below; Once you get your log file, you can download it to your local machine and open it with a text editor, i.e. Notepad++. When you open it, you will see all logs, including the error message. Please be aware, as most things with Umbraco, logging is also customizable, so you can either use the default Umbraco logging which is Micros

How to use JQuery Ajax Methods for Async ASP.NET MVC Action Methods

Making repeatedly calls to async methods can be a nightmare. In this case, it makes sense to use 2 ajax methods, instead of one. Here is a simple solution to overcome this problem. See that  ajaxcalls   is emptied after the success response for the first ajax call and then the second ajax method is used to make one single call to the async action method. Hope it helps. View: @section Scripts{     < script type ="text/javascript">         var smartDebitObject = new Object();         smartDebitObject.MembershipNumber = $( "#MembershipNumber" ).val();         smartDebitObject.ProfileId = $( "#ProfileId" ).val();         smartDebitObject.FirstName = $( "#FirstName" ).val();         smartDebitObject.LastName = $( "#LastName" ).val();         smartDebitObject.AddressLine1 = $( "#AddressLine1" ).val();         smartDebitObject.Postcode = $( "#Postcode" ).val();         smartDebitObject

Umbraco lifehack: How to setup anchor/jump links in Umbraco without making code changes

Today one of my clients created a ticket asking whether it is possible to set up anchor/jump links for an Umbraco content page so that they could link different sections of the page together. This is a common scenario for most Content editors and it should be super easy with any CMS platform, right? Houston, we got a problem! Now an anchor or page jump link is a special URL that takes you to a specific place on a page and it normally requires a unique HTML element ID to link different parts of a page.  When I investigated my issue, I realised that the page sections of the Umbraco page didn't have unique IDs.  View Source Code comes to the rescue In order to resolve the issue without any code changes, I decided to update the content using the built-in View Source Code feature of Umbraco CMS. This feature is available on built-in property editors, like Rich Text Editor and is super handy for checking the code that Umbraco generates for your Front-end website and making minor adju