Upgrades can be done by installing the extracted upgrade package over the existing site. After downloading the upgrade package and before extracting it, righ click on the file, select properties, and if there is an "Unblock" button displayed, click on "Unblock".

I would recommend upgrading first to 4.06.02. This and only this upgrade will require you to copy connection string information, machine keys, databaseOwner and objectQualifier values as well as any customized sections from your old web.config to the version 4.06.02 release.config which will then be renamed web.config. Keep an extra backup of the existing web.config just in case you have not copied values correctly.

Next, upgrade from 4.06.02 to 4.09.05 using the upgrade package which will not contain a web.config file. Your old web.config will be automatically updated.

Make sure that your site is running under an ASP.Net 3.5 SP 1 application pool and MS SQL Server 2005 or 2008 (standard or express - NOT SQL Server 2000!). Both are required in DNN versions 5.02.00 and above.

If you have the XML module installed, either uninstall it or upgrade to the latest version 4.03.05 as earlier versions are not compatible with DNN 5.3.0 and above.

If you have the Chat module installed, uninstall it. The latest version is not compatible with DNN 5.4.x

If you have a multi-portal installation or use a default language other than en-US, check the forums for additional tips on preparing for the 5.04.04 upgrade.

Next, upgrade from 4.09.05 to 5.04.04 again using the upgrade package and allowing your existing web.config to be automatically upgraded.

To give yourself an extra measure of safety, you may want to clone the installation following the 4.09.05 upgrade to a localhost install and perform a test upgrade to 5.04.04 before trying it on the production site. This is especially useful if you have third party modules and cannot first determine if they will work on 5.04.04.

As always, obtain a full backup of the installations file system AND database prior to each upgrade step in case you need to roll back due to a failed upgrade. Thoroughly test site function and upgrade modules to most recent versions that are compatible with the DNN upgrade version. If you are using third party modules, check the developer's or vendor's website for any known compatibility issues and available module upgrades. Once satisfied with the framework upgrade, obtain another set of backups and move on to the next upgrade.

I recently did 6 upgrades from various 4.x versions to 5.4.2 or 5.4.4 following this sequence. Only one had serious issues - and those were my fault as I had failed to realize that I was nearly out database space allocated on a shared hosting site. Thankfully I had made backups and could roll back after reducing database size/truncating database log.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner

You can do that but do need to watch out for a few potential problems:

1. If the new server is Windows Server 2008 R2 it will be running IIS 7.5 in which case the default ASP.Net worker process account is no longer Network Service. What ever account has been assigned to the AppPool in which the site is running will be the one to which full permission must be granted to the root folder and all descendent folders. Do a Google search on IIS 7.5 ASP.Net account or check the DNN blogs for more information.

2. I would first restore the upgraded DNN 5.4.4 site to an application directory running under an  ASP.Net 2.0/3.5 SP 1 application pool on the new server THEN after testing that the restore to the new server has been successfull switch the AppPool to ASP.Net 4.0. When the application restarts, DNN will sense the change to ASP.Net 4.0 and make the necessary configuration chages, etc.

3. Keep in mind that some extensions (DNN Gallery 4.3.0 is one - upgrade to 4.3.1 RC first) will not run under ASP.Net 4.0 due to much stricter parsing of markup, stricter request validation, etc. You might want to first do a test restore and switch to ASP.Net 4.0 before doing so with your production site.

4. No problem with machine keys, etc. when changing servers. If you will be changing databaser server as well, watch out for the "orphaned users" issue that often happens when restoring a database backup to a different database server.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner