When to upgrade your DotNetNuke website!

Well, the 4.8.0 release of DotNetNuke came out today, and some people are having some problems, so I figured I'd take the time to put together what I hope will be a short post with my professional opinion of how you should handle DNN upgrades. Here are some questions and thoughts you should have before you upgrade.  Does the new release offer you features that you absolutely need? If you answer NO to this question, then step away, go work on something else.

If you answered yes then you need to start thinking about how you will upgrade.

How are you going to upgrade? My advised method would be to do the following.

  1. backup your site (files) and your database.
  2. restore these backups in a test environment, with a test URL. 
  3. upgrade the test environment (see a previous post I made about upgrade steps)
  4. TEST TEST TEST, see what works, make sure nothing breaks. Some items that might break during an upgrade include
    1. Third Party Modules
    2. Core DNN Functionality
    3. Custom Functionality
  5. If your testing goes well, repeat Step 1 on your Production environment again.
  6. Upgrade your production site
  7. If all is well, you are golden, if something goes wrong with the Production upgrade Rollback to the backup you made in step 5 and then analyze what happened before you proceed

What are the most important steps above? #1 #1 #1

DNN has frequent releases, as large as the application is major releases do tend to cause problems, that is why there are frequent minor follow up releases. I'm a HUGE DNN Fan/user/developer/core team member so don't think I am knocking DNN in the least bit, but I tell everyone of my clients, NEVER upgrade a production site without testing it out first. I even recommend doing the above steps when you are upgrading or installing a new module, it is far better to be safe than to be sorry.

It really amazes me how many people see a new version of DNN available, immediately download it and upgrade a production environment, then complain when something breaks. You have to remember there are an infinite number of ways that DNN can be configured, from custom modules, database installs, to hosting environment peculiarities, many things that the DNN core team and beta testers couldn't possibly test for before a release. That is why you must do some testing yourself before you pull the trigger on any production site changes.

Posted from weblogs.asp.net/christoc

Recent Comments

There are currently no comments. Be the first to make a comment.

Add Comment

Please add your comment by filling out the field(s) below. Your comment may need to be approved before it becomes visible.
Enter your first name for display with the comment
Enter your last name for display with the comment.
Enter your comment here.
If you can't type DNNRocks in, you can't post, plain and simple.
Submit Comment Cancel

Chris Hammond

Chris Hammond is a father, husband, leader, software developer, photographer and car guy. Chris focuses on the latest in technology including artificial intelligence (AI) and has spent decades becoming an expert in ASP.NET and DotNetNuke (DNN) development. You will find a variety of posts relating to those topics here on the website. For more information check out the about Chris Hammond page.

Find me on Twitter, GitHub and LinkedIn.