Hello, I recently attempted to upgrade a 3 page web from version 4.9.4 to 6.2.0. This was a trial web, created about 3 or 4 years ago when I first started with DNN. I abandoned the attempt after about 20 hours - after all it was only a 3 page web and recreating was not a problem. This is the second time I’ve had to abandon an upgrade, so I spent the time to out why it was so difficult with the hope of avoiding the problem. Here is what I found:

• Backups are really important.
      You will use them at some point
  
• Local copies are really important.
      If you have a problem, it will only affect the local copy, not the customer facing copy
  
• Virtual machines are important
  A virtual machine with the same versions of the software used on the web server is necessary. I try to maintain my development system at close of the latest versions. I have no control of the server environment. The discrepancies are difficult to resolve - In my case my web server used SQL 2008, but my main development system has SQL 2010. No 3.5 version of .Net , on the local system. Running some versions of DNN in version 4 is not pretty, version 3.5 is required.
  

• 3rd party addons – use only if really necessary or allow extra time for upgrade.
  To me, these are the attraction of DNN. Unfortunately, they break the upgrade process. I found triggers inserted on tables causing the upgrade scripts to fail, dll version requirements incompatible with dnn and missing historical documentation. Installing the current version of a 3rd party addon, can destroy an older version of dnn so if the product states it only runs on version 6, believe it. Lifetime upgrades only mean the lifetime of the name package containing the product, if the package is renamed the upgrade ceases, pity it is really the same product.
  
  There are no solutions to some of these problems. They can be mitigated by keeping copies of documentation and not relying on the web articles remaining in place, using virtual machines and timely upgrades.
  
  Unfortunately, I found the upgrade problems rise exponentially with the number of 3rd party addons. I’d be certain the was a mechanism for extracting content should it be necessary to remove them for an upgrade.

• Instructions and documentation
  Only instructions and documentation tend to vanish from the web. You need to keep your own copies.

In summary, lots of the problems would be reduced if I’d not waited so long to upgrade.

---

fj

Thanks for the comment.  As Cathal states, those links are the place to start.  The information is accurate and the instructions work fine most of the time.  I always do what is recommended first.  The only time I've found when they don't work is when there are 3rd party products or your system has a later version of ASP.NET, Windows or whatever.  I suppose what I was really trying to say is the 3rd party providers and Microsoft's upgrade path do not always match DNN's.   When this happens I've found it best to upgrade to each stable release and fix the problems as they occur.  If you stick to the suggested sequence you jump releases and can get a whole lot of cascading upgrade failures from your 3rd party and a real mess.

---

fj

It seems I left a bit too much out of my original post.  I think I'm saying the same thing as Sebastian.  I see a role for a virtual machine in a test environment, not on the server.  I was thinking of something simple like the virtual PC that comes with Windows 7.  To me, it seems the best way of mimicing the live enviroment. 

On the live server cloning the web is an excellent strategy as it can be used for final testing and minimising down time when you actually transfer the upgrade to live.

For what it is worth, I support Sebastian's comments about only upgrading when necessary.

---

fj