Transfer of configurations during upgrade

When you upgrade your Sitefinity CMS project on your local development machine, you can easily transfer the upgraded .config files to the next environments from the continuous delivery process. You do not need to upgrade or merge the .config files manually. This is possible, because the versions of Sitefinity CMS and all application modules are no longer stored in the SystemConfig.config on the file system, but in the database.

The SystemConfig.config file stores the information about the modules state, but does not store their version or the error message data. These are stored in the database in a dedicated table – sfmodulevrsn.

Database table sfmodulevrsn transfers and stores the following:

• The global Sitefinity CMS version
  Sitefinity CMS versions 8.2 and below keep this information in SystemConfig.Build and SystemConfig.PreviousBuild.
• The static modules’s version and error message
  Sitefinity CMS versions 8.2 and below keep this information in SystemConfig.ApplicationModules for each static module.
  Table sfmodulevrsn stores modulename, version, previousversion, and err_msg.

Sitefinity CMS also uses a new UpgradeConfig.config file that keeps any data, which is deleted from other existing configurations, but is needed for the upgrade of the next environment in the continuous delivery process.

The following happens when you upgrade your project on your local development machine:

1. On Sitefinity CMS initialization (SystemManager.Initialize()), additional logic checks whether sfmodulevrsn table is empty. 
   If the folder is empty:
2. SystemConfig.ApplicationModules are saved in UpgradeConfig.ApplicationModules.
3. Version and error message for each module in SystemConfig.ApplicationModules are removed.
4. Table sfmodulevrsn is initialized with the current modules state.

NOTE: Modules which are uninstalled on the initial (development) continuous delivery environment are deactivated on the next environments. No uninstall logic is executed. Because the error message for each module is stored in the database, if there is an error for a given module on one of the NLB nodes, the module is deactivated on all other nodes.