From Umbraco v7 to Umbraco v9 – Part 1

Ever since we got such an enticing overview of it at Umbraco Spark in Bristol back in early 2020, I’ve been keeping a keen eye on the progress of the .net core version of Umbraco. I originally played about with a fresh project on the first Alpha release when it dropped late last year just to see how much was there in what was definitely being heavily caveated as an early release as it only handled back office. I even wrote up a load of stuff I meant to post up on here at the time. But as is so often the case, then forgot all about it until the moment had well and truly passed.

Fast forward several months and since then the frontend has been added in, and there have been several more Betas released. Inspired by the recent Codegarden 2021 virtual conference where all talk was on the imminent release of the first Release Candidate in July, and so many Twitter posts or meetup updates on the rapid progress of new v9-compatible plugins from so many others, I decided it was time to try again on the latest version again. Mainly to see how close to being able to build a production site I could get even with what is still officially a Beta.

Rather than just a hypothetical project this time, I actually wanted to try it on something real. Of course, finding a client site to run a production test on beta software on is not the easiest thing to get through. But handily at this point I was able to turn my attention to one of my own side projects TV Whirl. A site I will caution people with a design-eye that I’ve had online since 2001 now, albeit not in Umbraco for most of that time, so which still comes complete with some very old graphics and of-the-time css. The site was first built into Umbraco in version 7.5 originally without using the Models Builder approach, and was upgraded only once to 7.7 with a slightly bitty addition of models then. For a long while now I have been meaning to give it a full overhaul and rebuild in v8 properly, mainly due to the fact it has a large number of nodes in it (+50000) and I’d already seen just how fast 8 is with its caching compared to 7 (where I’d built a bunch of bespoke stuff to cache things manually). But heyho as we’re here now, I thought why not skip a generation and take it straight through to v9.

If you’ve been lucky never to have to go several versions on an Umbraco install, these next two blog posts chart this journey:-

Part 1 – Getting from v7 > v8

Due to very few changes to the underlying data schema, an Umbraco v8 database should work almost flawlessly with v9. However… that meant I had to have an uptodate v8 site first.

Step 1 – Upgrade the 7.7 site to 7.15.
As the v8 upgrader only properly supports the later versions of v7, I first of all had to get the project onto the latest version of 7. This seemed to go reasonably smoothly. Update the nuget package in Visual Studio. Hit rebuild. Run site. Watch installer back office upgrade. Done! Some of the frontend views no longer worked due to changes there have been in approaches over the versions, but I wasn’t too worried about fixing this as this bit was only a stepping stone and all the frontend code is planned to be thrown out for v9 anyway.

Step 2 – Migrate all obsolete datatypes.
This is where things quickly got a little more bumpy, just due to the original age of it. With the site originally coming from 7.5, it pre-dated all pickers being based off UDIs, relying on pickers which still use integer values internally. Although the old pickers were supported right up to the last version of 7, they were finally removed in v8, so before an upgrade to v8 is allowed all these obselete pickers have to be replaced. I first ran into this issue on a project in the early days of v8. As there weren’t many options available at the time, I’d had to do a lot of manual migrations then and some of the documentation around it at the time was a bit patchy, which overall made for quite a painful time. However we’ve come on a very long way since then with some fantastic documentation work and packages to help. I vaguely remembered hearing talk of a new release of a package to help with picker migration having come up recently either in one of the Friday umbraCoffee streams or one of the virtual meetups (and if you’re not already dropping in on these, I would implore you to do so). As is so often the case, I couldn’t for life of me remember the name of it when needed. However with being so sure I’d heard mention of something recently, a short bit of searching finally led me to a recent blog from ProWorks and the required nuget package Our.Umbraco.Migration . This worked flawlessly, and pretty quickly all those pickers were replaced with pickers which… well don’t really look much different, but internally it was what was needed.

Step 3 – Create a fresh v8 project
With all the v7 pickers migrated, the next step was to set up a fresh project in Visual Studio with a fresh copy of the Umbraco 8.14 package added initially. I decided to give that a quick run just to check the installer would fire up before doing anything else with it, but oddly for something totally fresh kept running in to some spurious factory errors. So in the end I just downgraded the package in nuget to 8.13.1 instead and this worked fine. I’m pretty sure I could probably have fixed the 8.14 issue with a little more time. But really it didn’t need to be on the absolutely latest version anyway as the v9 code works quite well with most recent v8 databases, and again this was just a stepping stone to be thrown away. (Coincidentally I only realised when doing a screengrab of the solution for the head of this blog post I’d actually created the v8 project in Visual Basic rather that c#, but with this just being a stepping stone again it went completely unnoticed. It could even be where the aforementioned spurious errors had come from, though I’d have expected it to affect 8.13 the same)

Step 4 – Hook v8 up to the v7 database
After confirming it worked to the installer welcome screen on this fresh copy, I went back in and hooked up this 8.13.1 project to the existing 7.15 database by changing the web.config connection string, ran the upgrader and… immediately couldn’t log in when prompted!

Step 5 – Fix user passwords
Thankfully this is something I already knew about as I’d done the headscratching on a different project before. This was originally a 7.5 site, and the default hashing method for user passwords was changed in 7.6. Since then Umbraco have continued to provide a ‘UseLegacyMode’ flag which has allowed you to continue using the old password method. So I just added this into the fresh v8 config, and all was good. However with me doing such a big update, I finally decided to get with the times and ditch this legacy password support. There are several ways of solving this, especially if you have access to proper email and password resets. But as I didn’t have a full mailserver up and running on the dev box, the easiest way I found is to:-
1) Run web.config with UseLegacyEncoding on for UsersMembershipProvider.
2) Login to an admin user.
3) Go back and set it to false again in web.config. Although this will restart the site, it should keep you logged in to your current session.
4) Create a second user and make a note of the newly generated password. This user will now have been created with the legacy mode disabled now and thus is created with the new hashing.
5) In the users DB table in SQL Management Studio, copy this second user’s password field into the original admin’s password field.
6) Logout and back in to the admin with your updated password for them now. You can now change the password however you see fit and it’ll all be on the new hashing method. If you have other users, you may need to reset those from the updated admin too.

At this point, I had no running frontend as it was still a largely fresh v8 project. However the all-important back office content was all in place, and ready for the next step. But with it already getting quite late, I decided to call it a night here. That’s where I’ll pick things up again in the second part of this.