This is only my opinion of course and I'm sure that others have their own, but I thought I'd share with you the procedure I used for upgrading my DotNetNuke websites.

I am weaning myself off the normal DotNetNuke builds moving towards the fully compiled, reduced dll version I have access to.  Some will call it a fork, but I call it DNN on steriods where it's really been developed to be what I would comfortable call a 'commercial grade' version of DNN.  I've been using it on many sites, but mainly from the DNN 4.5 era.  However, this post is not about my compiled build, but more the quirks in the upgrades between pre 4.6 builds.  That is ... 4.5.5 and earlier, to 4.8.

I used this procedure to upgrade many sites, and recently upgraded my Catalook support website, which was a 4.3 or something similar build. 

It seems we have to overcome the hiccup that has occured when 4.5.5 was released, with the introduction of ajax and changes I believe (but don't know in much detail sorry) to the membership provider.

Part of the ugprade process sees the naming convention with DLLs, a change in the HTML provider and these seem to stop the upgrade process from working correctly and in a streamlined fashion.

So the steps I'm giving you here are tried and tested on my commercial portals which actually require being used on a day to day basis.  I notice there were some other things I had to in the course of the upgrade to stop some common errors, but it was good to see that even after a few weeks, the event viewer log files behave nicely and are not populated with annoying errors.

Firstly - before you do anything, make sure you have downloaded or zipped up your site if you have a control panel.  The key to any updates on any site is to back up before doing anything... and that includes the database.

Once this has been done, prepare your update by having the latest download of DNN 4.8.3 upgrade  AND DNN 4.8.3 Install -

Unzip them both locally and from the  root/install/modules/  folder,  copy the html module and paste into the upgrade folder.

Make a copy of your config file - that's a given with DNN - once you are working in this space, you'll understand the importance of backing up config files so they are easy to go back to and rename quickly if you make a mistake.

Open up notepad and copy and paste your machine keys into there.
Copy your connection strings to talk to the database. Remember there are two locations.  They are different and you will need them both.

Sometimes, you'll also need to check the config file to make sure if you have other modules in there - such as PageBlaster, Inventua HRef Exchanger and other modules that write to the config file including some payment gateways. That's why we need to keep backups of our config files.   DotNetNuke does backup the file, but it's just handy for quick site changes.

If you have other config file entries apart from the machine keys - make a note on where they are -  and paste into notepad.

There are some very good file compare programs around, but we've done literally hundreds and hundreds of sites and found that good old notepad in this instance does the job just fine.

So, now that you've got the live files AND database zipped up and safely stored, and copied the html file over to the upgrade folder as shown in the diagram, you can start the next step.

SET YOUR WEBSITE TO BE OFFLINE. 

How do you set your website to be offline?
These instructions will show you and provide you with the necessary file to bring your site offline, and again, you'll find this a handy file to keep in your folder.

The reason you need to do this is because you will be deleting folders, files and dlls BEFORE THE UPGRADE PROCESS. 

This is how I have successfully done the upgrades and while not required normally, but in this instance is it necessary to streamline the process.

Once the file has been updated - Check that your website is actually offline by browsing there - you should only see the offline for maintenance page. If you can see that page, you can do the following -

Delete the following directories

Admin
App_code
App_globalresources
Components
Controls
Documentation
Images
Install
Providers

Delete files from root installation

Default.aspx / Default.aspx.vb
Dotnetnuke.vstemplate
Dotnetnuke.webproj
Errorpage.aspx / errorpage.aspx.vb       
Global.asax

Delete files from /bin

DNNSqlMembershipProvider.dll
DNNSqlProfileProvider.dll
DNNSQLRoleProvider.dll
Dotnetnuke.* (but leave the module DLL’s! dotnetnuke.modules.*)

So, anything that has .modules in it, leave it... they are the actual module files and what are doing is to remove the core dotnetnuke structure files, as they are the ones that have been rearranged and changed.

Copy the 'release.config' file and name to web.config file, and put in your connection strings as per the old config file which of course you copied across to notepad as I suggested earlier. .  The reason I always suggest you do this is because it's quicker than just renaming the file - if you make a mistake, then you have the copy to refer back to rather than having to replace the whole thing.

FTP the whole upgrade folder to the root directory and choose overwrite for any of the existing files. 

After the files have been uploaded, go to the domain/install/install.aspx file and the install progress should then step through the cycle and the usual - click to access your portal should appear.

Now, I have to let you know that this is just free advice, which I have shared based on how we have been performing the upgrades of sites that are 4+ and higher.  I am going to be upgrading quite a few more over the weekend but from 3.1.1 > 4.8 and will give you some tips on how we have done them.

Interestingly enough - XD Design website has been upgraded from 3.2.2 > 4.8+ using a similar process but it took me about 8 hours to go through it step by step.  You know, we didn't even upgrade a single module.  I have some modules installed from dnn 3 that still run withouth any change at all. And remember, I'm not a developer. I just use DotNetNuke to run my business and am sharing with you how we approach it, so you can ascertain if this level of work is within the scope you can do yourself.

Mind you - I have my own servers and we have a couple of hundred sites, so we actually log on to the server via RDP to do most upgrades.  This solution has been done using the FTP method with the uploading of files being the only difference here. So even without access to a control panel, as long as you can organise a DATABASE BACKUP from your hosting provider, you should be able to do this easily. 

You will require some FTP experience, but honestly if you can't even master that, then I'm thinking perhaps you would require a completely managed service, similar to what I offer where you never touch the code, the files, nothing - it's all done for you.  But that isn't a common offering by standard hosters.

I hope this helps you in your quest in running your business using the great open source solution  -DotNetNuke and that you feel more empowered even if you can't write code!

Nina Meiers