As most of you are aware, each environment and instance of Dotnetnuke vary depending on: the specific version of the framework; runtime settings of IIS; permission configurations on the files and management configurations of the databases and third party modules which affect both visual and behind the scene interaction. This variation tends to keep each instance of Dotnetnuke to itself, and since no two are alike, it is often not exactly simple to dictate the correct procedure for upgrades.

Obviously, no one can estimate each and every scenario when it comes down to this choice. It is often important, especially in key systems which affect your particular businesses, exactly how the applications should be crafted so that no *ill or unexpected behavior* is ever experienced.

This brings up a key point - how do you know when to upgrade?

Let's take into consideration a fairly stable environment, which while there is a constant ebb and flow of the community, the development has maintained on an even, and mostly uninterrupted course. No, I'm not referring to Microsoft here - but rather - the DotNetNuke application framework. Each upgrade is sometimes a bit of uncomfortable for many module developers and software vendors. Quite often, even though the framework has been tested and approved by QA teams, there is always the unknown. These unknown environments, off configurations, and customizations which we do not anticipate.

As a rule of thumb, I recommend holding off on an upgrade unless all the factors which are involved have given either a push or an okay on the change. Although, at times, this may mean an indefinite wait on the latest and greatest. Most often, the best recommendation is to always be one stable version behind. Meaning - don't always just make the jump for the sake of jumping. There is a reason why new versions are considered 'bleeding edge'. The amount of blood lost by the initial users of the new version is sometimes very high. But, as the edge is honed down, the version becomes stable, and all the issues are flushed out.

So - I've made up my mind to upgrade - now what?

When I personally make the decision, I almost always go ahead with the upgrade - in a safe environment. A staging or backup of my physical application. This staging environment shouldn't really use a separate domain name or even directory mapping. Instead, the app should be a complete clone, from the front down to the domain names and handling. The test-bed machines should configure their DNS settings to point to it instead of the production system. This way - you are certain that everything is as it should be, after all - it is your web presence.

With that said, my systems spend a great deal of their time running everything on beta. So - maybe you shouldn't take my advice after all!