From my experience, there are three factors influencing the success of upgrades:

• number on 3rd party modules
  This is the main issue I encountered. Always try to check the developers site for available upgrades first
• consistency of the database
  is is always best practice to check the content of the database before upgrades, although it needs to be done manually and required deeper knowledge of DNN's internals. If you upgrade a version prior to DNN 3.3.0/4.3.0 to latest DNN version, I suggest to make a beackup and clear the content of the following tables:
  • EventLog
  • Files
  • Folders
  • SearchItem
  • SearchItemWord
  • SearchItemWordPosition
  • SearchWord
• version number
  the longer you wait, the more changes are needed. Especially if you are doing a DNN 2 upgrade, I suggest to upgrade to DNN 3.0.13 first and in a second step to latest DNN 4.4 version.

And another note: if there are issues listed during the upgrade, check the associated log file, even if the portal seems to run fine, because an issue can lead to problems with future upgrades.

This is incorrect. DLL's are loaded as requested and the GC unloads and cleans them up as they are not needed.

The don't call it "managed" code for no reason. ;)

Ed.  The original statement is correct for the default Asp.Net behavior.  If you look in C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG at the base web.config file you will see a section like this:

        <compilation>
            <assemblies>
                <add assembly="mscorlib" />
                <add assembly="System, Version=2.0.0.0, Culture=neutral, ..." />
                <add assembly="System.Configuration, Version=2.0.0.0, Culture=neutral, ..." />
                <add assembly="System.Web, Version=2.0.0.0, Culture=neutral, ..." />
                <add assembly="System.Data, Version=2.0.0.0, Culture=neutral, ..." />
                <add assembly="System.Web.Services, Version=2.0.0.0, Culture=neutral, ..." />
                <add assembly="System.Xml, Version=2.0.0.0, Culture=neutral, ..." />
                <add assembly="System.Drawing, Version=2.0.0.0, Culture=neutral, ..." />
                <add assembly="System.EnterpriseServices, Version=2.0.0.0, Culture=neutral, ..." />
                <add assembly="System.Web.Mobile, Version=2.0.0.0, Culture=neutral, ..." />
                <add assembly="*" />
                <add assembly="System.Runtime.Serialization, Version=3.0.0.0, Culture=neutral, ..."  />
                <add assembly="System.IdentityModel, Version=3.0.0.0, Culture=neutral, ..." />
                <add assembly="System.ServiceModel, Version=3.0.0.0, Culture=neutral, ..." />
            </assemblies>

Notice about three quarters of the way down that there is an entry of assembly="*".  This tells Asp.Net to load all assemblies in the application \bin.  This behavior has been verified with Scott Guthrie and the Asp.Net development team at Microsoft, and has been thoroughly tested by us in a test lab setting.

If you look in the latest versions of DotNetNuke (4.4.0+) you will notice that we added the following section to the web.config:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="bin;bin\HttpModules;bin\Providers;bin\Modules;bin\Support;" />
    </assemblyBinding>
  </runtime>

This allows us to move some assemblies out of the \bin directory so that the default \bin loading behavior is ignored and instead those assemblies can be loaded on demand.  The probing element tells the runtime to look in these additional directories if it does not find an assembly in the GAC or \bin directories.

So, to sum it up:  If you are not using a module on your site, then uninstall the module. It will increase your startup performance.