Upgrading the Wanderly platform from Umbraco 7 to 8

With the new version of Umbraco released last year we wanted to take advantage of some of its new features to improve the Wanderly platform — 3sixty’s smart website builder for online travel providers.

Along with improvements to speed and security, Umbraco 8 comes with support for multilingual content in the form of the new ‘language variants’ feature, a way of varying pages by culture. This will allow users to create different language versions of their site and easily maintain the content.

There are also improvements to the back office — a redesigned interface with improved editing tools and a bigger workspace. Additions such as ‘infinite editing’ allow seamless switching between documents and ‘content apps’ — which can be used to enrich the editing experience. For people using the platform this means that editing their site will feel much simpler.

Upgrading

As there are many breaking changes in Umbraco 8 it is not just a straightforward upgrade, there are two parts to the process, migrating the content and upgrading the code. Fortunately Umbraco provides some pretty good documentation to help you through the process.

Wanderly is built using a baseline in Umbraco cloud, a feature which allows us to create multiple sites based on an existing project. This means improvements can be quickly pushed out to any sites using the platform. It also means that there are two steps to the upgrade, upgrading the baseline site and migrating the data across from the child projects.

Migrating the content

The first step is quite straightforward, the content needs to be migrated to a new version 8 site. I started by running the baseline project locally and restoring all content and media from the live site. Then, I created a brand new version 8 site in Umbraco cloud and cloned it.

To migrate the content, I took the database file from the version 7 project and added it to the version 8 project. Updating the version value in the web.config of the new project to the old project value will trigger the database migration.

Depending on the project a few changes may need to be made to doc types before being able to access content. One of the main examples of this is nested content. These now need to use the ‘is element type’ property. Without this being checked in the permissions, the doc type won’t be available as a nested content item.

A few property editors such as the dropdown editor and the radio button list did not migrate successfully and resulted in JSON serialisation errors. In these cases, removing the property editor and recreating was the simplest solution. A list of some of the current migration issues can be found here.

For projects running in Umbraco cloud, it is also important to regenerate the UDA files. These contain metadata and important information for the types created in the back office.

Upgrading custom code

The second part, upgrading the code, is a little more time consuming and depending on the size of the project and complexity of custom features could take a lot of work.

Any media and assets can just be copied across but any additional code will probably need some adjustments before the new project will build.

Although not recommended from 7.4+ Dynamics are no longer supported and there have been some changes to the way published content is rendered.

A few of the main changes I found are:

  • Template files need to inherit from Umbraco.Web.Mvc.UmbracoViewPage<ContentModels.HomePage> instead of Umbraco.Web.Mvc.UmbracoTemplatePage<ContentModels.HomePage>
  • Template files need to use ContentModels = Umbraco.Web.PublishedModels instead of ContentModels = Umbraco.Web.PublishedContentModels
  • @Model.Value(“propertyAlias”) replaces @Model.Content.GetPropertyValue(“propertyAlias”)
  • .ContentType.Alias replaces .DocumentTypeAlias
  • Pre values are gone in Umbraco 8 Model.Value(“propertyAlias”) replaces Umbraco.GetPreValueAsString(Model.Content.GetPropertyValue(“propertyAlias”))
  • GetCropUrl() replaces GetCImageCropDataSet

Migrating the child projects

I couldn’t find any information specifically about the upgrade process for child projects, so I followed the same first few steps as for the baseline: migrate the content and make any changes to the doc types and property editors.

With larger projects the database migration takes a little while. I found that after around 4 hours the migration appeared to stop and error but on inspecting the content tree, the content had fully migrated.

One of the main challenges with this part was schema mismatches. It is important that any changes made here need to match changes made to the baseline, If they don’t, when it comes to pushing the content to the live site there will be errors.

Whilst upgrading to version 8 has been quite a laborious process, it’s definitely worth it for the new features. It’s a big step up from version 7 and contains helpful improvements for editors and some interesting new functionality that will benefit wanderly, and those who use the platform.