Why a Kentico MVC Upgrade Should Not be One Hour of Work - Part 2
Introduction
In the second part of the series, I am going to continue on with the reasons why Kentico Upgrades take what they take and answer the $64,000 question as to what should an upgrade take for a Kentico MVC Site. Be sure to read part one first of the this two part mini blog post series about Why a Kentico MVC Upgrade Should Not be One Hour before continuing on.
Not Done Until It Says So
Since the Kentico admin tool is the core of the platform, we need to ensure an upgrade is done perfectly. Even though Travel Rock Stars might not be using a ton of Kentico features right now in the current state, they might in the future use many features like Marketing Automation and Content Personalization. This means Kentico still needs to work correctly as well as the live site. We would hate to have the upgrade go "ok", but not perfectly, and 6 months down the road when Travel Rock Stars goes to use Marketing Automation features, something comes up and says error, this is the 11.0 version of the Marketing Automation trigger on a 12 install (just a high-level example). So again, it is more on testing out Kentico as a whole part, after the upgrade and hotfix.
Remember after each major upgrade 10 -> 11 -> 12 you MUST run the solution one time to ensure the Run Once package successfully executes. If you don’t see a message that says upgrade completed successfully you should not go any further, and might need to restart that step of the upgrade.
Don’t forget the post upgrade steps in the instructions either! It is important to re-sign the macros and do the other things the steps mention.
Differences Between a Full Upgrade and a Hotfix
Even though both types updates share the same type of process (basically a SQL script and code update), they are not really that alike. A Kentico Upgrade consists of major updates to the product that have spanned a year's worth of work from multiple developers and engineers over at Kentico (and sometimes more time than that). The upgrades typically include new features, entire code re-writes of specific features, compilation optimizations under the hood, removal of features, and most importantly major Kentico API updates happen.
That last part is the one that really affects your custom code. If you have portal or MVC code in your solution written against a Kentico API like CMS.Membership.UserInfoProvider.GetFullUsers() and Kentico decides to remove that API and instead force you to use CMS.Membership.UserInfoProvider.GetUsersDataWithSettings() your project will error at compile time. By the way, this is a real example.
It is up to the site owner or developer to make the correct updates for the newest version of the Kentico API that you are using. Kentico actually published the changes to devnet, which makes it nice to find the answer of where to update your code to. The last time I checked for the v12 release I saw about 700 different API changes in the log. Now you may be using 0 of those original APIs and not have any issues, or 200 of those original APIs and now you have a bit of code refactoring to do. It all depends.
Upgrades also make changes to the how the solution is setup at project code level in visual studio. There is a different project structure in version 10 than there is 12 and so on when it comes to MVC. Version 12 has a unique way of installing the starter site and admin tool in a root folder compared to earlier versions. Also, the project structure has different versions of reference assemblies (dlls). If you have other custom libraries that are compiled against specific versions, you will have to update those as well.
These last few items will change your build process if you are using Continuous Integration (CI). You should be aware of them by now hopefully. Again, this is another reason why upgrades are more than an hour that might not be clear to non-technical users.
Kentico Hotfixes meanwhile are nowhere near the amount of change that a major point version is. The reason for that is the fact that Kentico launches a hotfix a week (almost) to fix and small bugs, or any small third-party dependency changes as stated in their 7 day bug fix guarantee. For instance, a hotfix could include an error in the admin tool when saving site specific roles or global roles, or saving a media library file item to Azure Blog storage. Or a hotfix might resolve the fact that the Twitter API now requires TLS 1.2 instead of TLS 1.0 to connect. Hotfixes are meant for small issues to be resolved only.
Pro Tip: Hotfixes are found at https://devnet.kentico.com/download/hotfixes. The Fixed bugs link is incredibly useful to find out if the issue you are dealing with is resolved in a hotfix or not. You can search for something like “smart” and all Kentico Smart Search issues will show up.
This means the chances of a hotfix breaking things on your Kentico site is less than an upgrade. But it doesn't mean the chances are zero! In fact, we have been bitten by hotfixes over the years, and are now selective about which hotfixes we apply and for what reason (that sounds like another blog post for the future).
Pro Tip: My advice to our clients is that you don’t want to Hotfix every single week, you also don’t want to never hotfix either. I recommend hotfixing not to the bleeding edge either, unless you need it. For example as of 2/18/19 I would choose hotfixing to 12.0.9 because it has a content staging fix in it and should be stable, but not running 12.0.10 because it is so new.
Upgrade/Hotfix Tools
Kentico does provide a set of tools to make this work a bit easier. I’d like to point them out.
- Kentico Upgrade X to Y exe
- This is the main executable you download to run an upgrade. This is absolutely required and critical (this same style exe is available for hotfixes as well). It is found on the Kentico DevNet download page.
- Kentico Upgrade Instructions
- Yes I include this as a tool, because too many people skip it. RTFM people! There are critical pre and post upgrade instructions that you need to keep an eye on when performing an upgrade
- Kentico Code Upgrade Tool
- I have a love / hate relationship with this tool. In theory it is great, it will scan your entire code base and spit out an excel style report of where you are using old API methods and tell you the correct method to change to. It would be nice if it worked better. The problem is that most of the time the report is not useful because most of the results are generic messages that don’t help, and you still have to figure it out.
- Bottom line this is useful for people who have not performed upgrades before, but for seasoned Kentico developers, it is faster to just deal with the API changes in Visual Studio at compile time.
- There is also a mode which will go through an automatically make changes to your C# code to resolve the issues. My advice to you, pretend this doesn’t exist and never use it. “Just” trust me.
- Kentico Installation Manager (KIM)
- The most valuable tool when it comes to hotfixes because you can point it at an installation of Kentico and it will hotfix that installation for you. This tool comes with the main Kentico installation on your machine. Sometimes people miss it entirely, so if you type KIM at your start menu, you should see it popup (again if you went through the full Kentico installation (website plus program files)). Download this from client.kentico.com in the form of the full Kentico 12 exe package.
- I used to use this all the time when hotfixing Kentico portal based websites. It does work well, however, in sites that have been running for 3+ years that have lots of data in the OM_ and Analytics_ tables, this utility tends to time out on the SQL Script running, so I don’t use it any longer. Instead I download the hotfix, extract the SQL Script from the folder and run that via SSMS to get around the timeout issue. Plus, I’m not sure how well it works with MVC (this might be a good topic for a future blog post).
The $64K Upgrade Question
At this point you are probably wondering, at the end of the day, how much does a Kentico MVC Upgrade Cost? My answer truly is… it depends. Sorry there is no automatic number you can use here. But I'll boil it down to a bullet list of what to consider when estimating a Kentico Upgrade.
- How many versions are we upgrading?(11 to 12, or 9 to 12) (each version has some effort as upgrades with Kentico are linear, you can't skip versions)
- The general rule of thumb for simple sites that I use is 6 - 8 hours for "intermediate" versions (intermediate is defined as a version that you are not going to stop at, example v10 is intermediate if you are going from v9 to v12), and then 16 - 32 for the final version that you are going to stay on (v12)
- How many environments do you have in your organization? (dev, stage, qa, uat, prod)
- Each environment needs to have the upgrade process run on it. Sometimes you can get away with restoring upgraded backup copies of databases and codebases, but not always. Typically, you perfect the "process" of the upgrade on dev, and then re-apply that process to all of the environments in your setup. Each of them takes time.
- For example, if you have a dev and production environment, the first run of the upgrade on dev could take you the 30 ish hours, and then applying the process you know works to production could take 2 hours more (hopefully less) but that 2 hours counts another round of backups and communication to your team about possible downtimes.
- How complex is the site that we are upgrading?(simple brochure site, complex marketing site with MA and Personalization, full blown e-commerce) (this determines the amount of testing required).
- Each area could take 1 - 2 hours to test if you have complex admin functionality inside of the admin tool.
- But if you have custom integration code with CRM or ERPs, that solution needs to be fully re-tested as well.
- Portal Engine or MVC? (portal engine requires some effort to test that SQL WHERE clauses work, custom macros work, and other portal type objects) (MVC doesn't require as much effort as the portal, but it still requires effort for updating the NuGet packages)
- Another 4 - 8 hours could be budgeted here, again depending on complexity.
- How much of Kentico are you using? (just the content tree? then it is simple, but are you utilizing custom form controls, custom modules, or vast amounts of custom code, then it is not)
- Do you want to capitalize on newer Kentico features?(like Kentico 11's email builder or Kentico 12's page builder)
- This could easily add hours per email template or per widget that you want to support in your upgrade if you are upgrading from version 10.
- Post upgrade tasks(this is an easy category to miss in estimating an upgrade)
- If you read the fine print of the upgrade documentation, each Kentico version typically requires some massaging at the end of it.
- For example, v10 make a larger change to orders and tax calculation, you need to run the provided script after the upgrade is complete
- V11 made a big change to contacts and subscribers, as well as email templates, post upgrade you again need to run scripts to update this correctly.
- V12 doesn't have as many post upgrade steps, but you still need to think about the time it will take to re-sign macros, purge staging tasks, and re-enable web farms.
Conclusion
Bottom line, the answer is, we have done upgrades for as little as about 32 hours of time for simple sites with just a dev and production environment, and as high as 300 hours for large complex sites with lots of integrations and multiple environments. It all depends.
When it comes to hotfixes, the final number that we usually go with is approximately 12 - 16 hours as they are much less effort, but still require the same level of care and user acceptance testing.
I hope that after reading this blog post you have learned a few details on why a Kentico MVC Upgrade / hoftfix does not "just" take a few hours.
