Blogs

Understanding and Mitigating DotNetNuke Upgrade Risks

18 Nov

With all of the recent changes that have come to the DotNetNuke product in the past few years I have been seeing more and more situations where users have older installations that want to get to DNN 6.x to take advantage of the new features that are available with the latest version.  I can't say as I blame them the newest features are great and a true benefit to all that use them, however, the road to getting there isn't always as peachy as it might seem, as you often find people with upgrades that fail horribly.  This has been a common trend and some of the things that DotNetNuke Corporation has done really makes this process less error prone, but a bit portion of the "getting it right" upgrade process really falls in the hands of the site administrators that are going to be doing the upgrades. That is the focus on this blog post, how can we as site administrators identify potential risks and then mitigate/resolve the issues on our own?

To properly cover this topic I have to start to look at things in a few sections.  First we start out with "Knowing your Site" and then we continue to "Knowing the Major Changes" and lastly "Knowing your Third Party".  If you take the advice in these three sections you will have much more pain-free upgrades of your DotNetNuke Installations.

Knowing Your Site

Out of all of the recommendations that I give clients when working with DotNetNuke this area is really one of the most troubling areas.  It is very important for you to know the details about your site.  What do I mean by this?  Well it is pretty simple and works something like this.

What third party modules do I have installed?  Where/When was my skin created?  What is my current version of DotNetNuke?

None of these questions are all that hard to find the answers to, but they can be very integral pieces to the upgrade puzzle.  For example, knowing which third party modules you have installed will allow you to properly analyze and research which modules are out of date, and which modules might have critical updates that are needed before/after you upgrade.  This topic will be discussed in more detail in a little bit.  Also, knowing where your skin came from can be a very important task, as DotNetNuke evolves there are changes to the way that Skins work and the various skin objects that are used in your skin.  By knowing where you skin came from you can know where you might need to go if you have an upgrade issue.

Knowing the Major Changes

Do you need to know each and every little change that has been done with each various DotNetNuke Version?  No, not at all each release has so many changes in it that it would be impractical to know all of them, but it is important to keep in mind some of the highlights that you might run into.  For example a few of the most notable ones are below.  (Version numbers are approximate)

  • 4.6.x - Inclusion of XML Merge ability for upgrade allowing for streamlined upgrades and no longer needing to modify the web.config
  • 5.2.x - Inclusion of Telerik Web Controls by default
  • 5.3.x - Migration to "Soft-Delete" of user accounts

Now these are just a few of them that I know off the top of my head, but why are they important and how would we know?  Well if you follow DotNetNuke on a regular basis you will end up hearing about a lot of these items, otherwise you can do just a little bit of research and find the key highlights with each version.  Now why do I have these out here as three of my important examples?

The first one with XML merge was a major improvement for the upgrade process and made it so that users did not have to manually merge web.config files on upgrade, this substantially reduced the number of errors on upgrades.  The inclusion of Telerik was another that I mentioned as it provided great benefit for the core, but it was a major, major roadblock for some of us.  For example if you had a DNN 4.x skin that was using the Telerik RadMenu, upgrading to 5.2.x would kill everything because of a DLL conflict.  Knowing that Telerik comes with the install though, and knowing your skin makes it so you can get an updated skin, THEN upgrade!

Knowing your Third Party

With DotNetNuke the Third-Party marketplace is one of the biggest keys to why the platform is so successful, but it is important for site administrators to "remember their vendors" and stay up to date.  This is especially true with modules that might have a tight integration to core APIs or functions.  These modules, at no fault of the developer are very susceptible breaking with various DotNetNuke version upgrades, however, if you stay up-to-date with your third party modules you will be made aware that "Version XXX is needed for DNN xxx and later" or similar messages that the vendors put out.

To do this though, you have to know what modules you have, what version you are one, and what version you want to go up to.  Now this sounds like a lot of hassle, but honestly it isn't that much work, and with any site you really should know what is going on.

Conclusion

With a little bit of focus in these three areas site administrators can greatly minimize the risk associated with upgrade and have a much higher chance of a successful upgrade.  I hope this has been helpful, feel free to share other recommendations below.

tags: DNN, DNN Administration
comments powered by Disqus

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Connect with Mitchel

I hope the information here has been helpful. To stay connected you can also subscribe to blog updates via email, contact Mitchel about consulting services, or reach out for assistance via CodeMendor

Content Copyright

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.