A content-friendly Kentico upgrade process

Posted: 1/14/2018 3:51:54 PM by Chris Bass | with 0 comments
Filed under: How-To, Process, Upgrade

Kentico upgrades tend to be quite the process, especially when you are multiple versions behind. The documentation is clear and effective on how to perform an upgrade, but it can be time consuming. Many clients don't want to turn off their site, lose form-entries or other user-data while the developers are working through all of the API changes and bug fixes needed to match the new version. Because of this, I wanted a process to manage upgrades with minimal downtime to the client.

In order to prevent site downtime, I recommend a two phase approach to perfoming an upgrade: The code-resolution phase and the deployment phase.

The Code-Resolution Phase

In this first phase, you'll pull down a copy of the production site and follow the upgrade steps Kentico outlines as normal: Get the site such that there's no compilation errors (including in Virtual Files), run the code upgrade tool, run the upgrade itself, then resolve any Code Upgrade tool-reported issues and any new compilation issues, and finally test. Repeat this process for each version as normal.

The difference is, each time you have a working site, you're going to take a backup of the site codefiles, including the Virtual Files (so, right after resolving the first set of compilation errors, but before running the code upgrade tool, then again after merging in the code upgrade tool changes and testing, but before starting on the next upgrade in your upgrade path).

During this process the client just needs to have a *code* freeze, or at least be in contact with you about any code changes so you can merge them into the resolved code.

The Deployment Phase

When your client is ready to push the upgrade, you now will need to initiate a full content freeze (or at least start tracking content changes so you can more easily merge them in at the end). Now you'll take another copy of the production site, but this time you have backed-up versions of the corrected current-version site, and code-corrected versions of all of the intermediary and final upgrade points.

This allows you to just run one upgrade, copy-over the corrected code for that version, run the site to execute UpgradeProcedure.cs, and immediately begin the next version. You can feel confident that your site will compile at each step and that the upgrade process should complete without any trouble, and you should be easily able to verify the site and deploy it.

As you can see, this phased approach allows for a much smaller window where clients would need to have a content freeze, making it easier for them on the business side, while also giving the developer a solid, well-tested process for your upgrade.
Blog post currently doesn't have any comments.
 Security code