Upgrading to Kentico 9

Kentico 9 release

Kentico 9 was officially released to the public on Tuesday 24 November 2015, at the annual Kentico Connection conference in Kentico's home town of Brno, Czech Republic. I was lucky enough to be at the conference, including the official launch party!

There's been a huge buzz around this release, especially among solution partners such as Luminary, as it represents a huge leap forward for the platform. In addition to a slew of tweaks, improvements and optimisations, Kentico has really stepped up its game with some modern enterprise-level features such as class-leading Continuous Integration (CI) tools, ASP.NET MVC development support, and brand new Integrated Campaign Management which allows marketers to harness the huge volume of data behind Kentico EMS.

Luminary as the guinea pig

Reading and talking about features is all well and good, but I needed to actually use it! So what better candidate to test the upgrade process than www.getstarted.com.au itself?

The Luminary website is a good choice for testing an upgrade, because it's not hugely complex, but not completely out-of-the-box either! For example:

• it was built on an earlier version of Kentico and had already been upgraded in the past, or in other words, it wasn't a fresh 8.2 build
• its codebase is in Source Control, with multiple environments and CI in use
• it's running Kentico EMS with database separation
• there are some customisations, including custom macros, global event handlers, and custom scheduled tasks
• we've done some pretty funky things in some of our transformation and custom web parts!

How was the process?

Warning: it gets a bit technical here!

The process I took to upgrade looked a little like this:

1. Convert the project from a website to a web application

This is not a necessary step in every upgrade, but in this case I decided it would be beneficial, and I'm happy to say I was right!

The key benefit for us was being able to build the solution in Visual Studio, and see every custom code-related upgrade issue immediately in one big list, including warnings that we might want to update code even if it wasn't going to cause an error.

For more info on websites and web applications, see Kentico Technical Evangelist Bryan Soltis's excellent post: Kentico Web App vs Website: Which One Is Best?

2. Run the upgrade on a development environment

This is a crucial best practice recommendation for upgrading any site. The last thing you want is for the upgrade to break something in your live site! At the very least, you can know that your live site isn't going to go down while you're working on the upgrade.

We chose to use the separate upgrade executable package, rather than upgrade through KIM, because we wanted to have the SQL scripts available for running against other environments later on in the process.

3. Fix the bugs!

Kentico 9 is a major version upgrade, and as such, you should not expect all of your code to be completely issue-free.

Once we were running in a web application however, fixing issues was relatively straight-forward. Simply build the solution in Visual Studio, and work through the list of warnings and errors it gives you! Of course you should also do full end-to-end testing of your development environment afterwards and keep a close eye on your Event Log, but you'd be amazed how far just building and fixing those issues will take you.

The Kentico DevNet also has an incredibly handy API Changes tool which makes addressing your issues much easier, as you can just search for a keyword there and get a recommendation for what new namespace, class or method you should be using.

4. Deploy

Our deployment chain makes use of source control and a CI server to take deployments out of the untrustworthy hands of humans. This is great for pushing up simple changes or new features, but it gets a bit trickier with an upgrade. Luckily deploying a Kentico upgrade can be broken down into a few clear steps:

• Take site offline
• Upgrade database (using .sql files)
• Upgrade files (add, replace or delete)
• Bring site back online

All four of these steps are very important to any Kentico upgrade, be it a major version, minor version, or a hotfix (see Boris Pocatko's upgrade best practices webinar).

Luckily by using source control and automated deployment tools we can be very confident that the changes we're deploying are the exact changes we made to successfully upgrade our local development site, so we can move through those four steps very quickly on each of our environments in the deployment chain, for example dev, test, stage, live.

All up, our upgrade was 100% complete within two days, and we experienced very few issues. In my opinion, the upgrade was easier than going from 7.0 to 8.0 last year.

Upgrading to Kentico 9 - what to expect

Welcome back to the non-technical readers!

Upgrading every site will be a different experience, but here are some common elements to remember or expect when upgrading any site from 8.X to 9.0:

Downtime

This is a major version upgrade, with some significant changes under the hood, so you should plan for and expect some downtime. With proper processes in place, it should be possible to limit this downtime to less than an hour, but it's still probably a good idea to plan for it to happen after hours or in a low-traffic period. Of course, if any downtime at all is unacceptable, we may still have a magic trick or two up our sleeve...

Upgrade in a development environment

Even if your code is perfect (sure it is) and you're confident the upgrade process will go smoothly, I can't stress enough that the upgrade should be done in a safe development environment, not directly on your live site.

API changes

There are some breaking API changes in Kentico 9, but not many! The big changes this time are new features or enhancements, rather than major rewrites of existing modules. Still, you should expect that there might be minor changes required to your custom code.

Database changes

One major yet largely transparent change in this version is some optimisation of the underlying database views that drive much of the content management side of Kentico. This won't affect most customers other than making things faster, but if your project involves heavy customisation involving database tables, this could be one thing to look out for. Ask your developer or agency if this is likely to affect you.

How much will it cost?

Great question! This was one of the questions that prompted a lot of discussion on the MVP panel at the Kentico Connection conferences this year.

At the lower end, for a very basic website with little to no customisation, I believe an upgrade is achievable within a day of development time.

At the higher end, if you have a particularly large or customised project, you could be looking at a week or more of development time, plus significant time spent testing, remediating and deploying across multiple environments. Add to this that you're probably going to want to deploy outside of hours. The good news is that most major integration points such as ecommerce or CRM have not changed as much as in previous versions, so it's not as scary this time!

Hopefully I've provided enough info without completely avoiding the price question... But seriously, the only way to know how difficult (and therefore costly) it's going to be to upgrade your site is to contact your developer or agency, and ask.

If you're one of our awesome clients, get in touch and we'll be happy to give you some more info and a ballpark estimate.