The first step in my process of testing a DotNetNuke upgrade is to get a duplicate copy of the site you are going to upgrade. This involves taking a copy of the file system, as well as the database and restoring them as  a new site. I always use the same names for the directory/virtual directory and database except I add “TEST_” as a prefix to clearly identify it. After I get everything copied, I then setup my new IIS virtual web server and assign it some new host headers (ie. test.domain.com) and make sure I have a nice robots.txt in the directory that blocks everything (. The next step is to add a portal alias directory into my PortalAlias table on in my database. Once we have this and the connection string in the web.config has been updated, we are ready to test the copied site to make sure everything is working PRIOR to attempting the upgrade (This is a minor but important detail I find most people overlook). Once I have the site loaded and I can login once as host I make sure my control panel is set to the core one (as sometimes we @ AppTheory use our own custom version) because sometimes this changes and will cause immediate errors after the upgrade and you can only fix directly in db, so take care of it now if you remember.

One final thing before starting my upgrade, I generally take a backup of my new TEST_ database as well as my new TEST_ directory. This ensures that if my upgrade fails I can quickly roll back and save myself the time it would take to repeat the steps in the first paragraph. To continue, I download the appropriate upgrade package of DotNetNuke and unzip it onto the server. I then grab the release.config and use Beyond Compare to compare it to my copied web.config to see if anything has changed. If anything is different, I merge the changes and save the file as my new web.config for my TEST site. I then copy all files from the Upgrade package over top of my TEST site making sure to replace existing files and that I also replace the web.config with my merged one from the previous step. Now I call up my test URL in my browser and let the process begin. Once the installation finishes, save a copy of success/failure messages (especially if there is a failure) so you can reference it later. Remember, if you have SqlDataProvider install issues you can find those in your siteroot\Providers\DataProviders\SqlDataProvider folder. At this point, all you have left to do is update your modules, providers and any third party controls (so long as you didn’t have other install issues) and do lots of testing.