Upgrade Process Improvements

Hi all,
We are looking into ways to optimize Sitefinity upgrades to ensure a more optimal experience to those of you transferring to new version.

We are discussing some options internally but wanted to hear from you as well:
--  What are the major pain points you encounter with upgrades?
--  Do you have any ideas how we (from a product standpoint) can help?

Any ideas are welcome and appreciated.
Best,
Kalina

- I would like all webconfig binding referenced updated, Telerik.Web.UI\Telerik.OpenAccess, etc...not just the ones added by the project manager.

- Some way to view\detect issues like pulling failed module upgrades from the system.config and restarting\retrying them, or like an upgrade completes\status page for users who don't know the tricks?  #1 thing after an upgrade is complete is to check that file, not everyone knows this.

- Project manager option to close not minimize to the system tray

- Fix the flakey backend UI version number (the one at the bottom), for some reason it's often wrong.  Like it might say Sitefinity 8.0 if we're on 8.1.

I mean by and large it's pretty smooth to upgrade...this is all nit-picking.  3.x was always a nightmare to update... I really don't have many complaints here.  Would rather you guys focused somewhere else really.

Installing the nuget packages has remove some of the issues upgrading.  What's still a pain is the we.config upgrade and the content files I need to add to solution.

II don't want to have to download an exe to do the upgrade.

Maybe there could be an http module that double checks all the files are in the correct places and if possible make less use of main config file, ones in subfolders are fine as I won't touch them and upgrade becomes just replacing them 

I agree with Betty. It would be nice to be able to just upgrade via nugget rather than the project manager. The only reason I use it is to ensure it updates any content files and web config.

I also agree with Steve. I don't have any major issues upgrading projects. Even old 5.x ones. I would prefer efforts be used else where.
Or perhaps write a really in depth white paper on upgrading for those that haven't done it often.

Thanks for asking for feedback, Kalina. Good suggestions in the above posts! Please find my thoughts below:

1. I would like to not only have release notes about what's fixed in the new release, but also a (tentative) list of upcoming bug fixes in the next one or two releases. If there's anything useful in a next release it saves me lots of time to postpone the upgrade until then. An upgrade is not just an upgrade. It also involves lots of tests to make sure the new version is safe to use in production. Usually we find issues so this (time consuming) step is required. I rather do it once than twice.

2. Currently one has to enable all disabled modules before upgrading (at least, I was told so in support ticket 748094). It would save time not having to do this. It seems logical to upgrade disabled modules too, so that they're ready to use when necessary.

Hi all,
Thank you for your feedback.
I will share what we are implementing.

1. We will introduce a new option to improve the upgrade process for NLB scenario.
Option (IgnoreDowngradeExceptions) to have OLD version of the Sitefinity DLLs to work with the New (upgraded) database/s.
Let’s share more information about way we would like this functionality...
When there is more than one node the upgrade process will happen in the following scenario (for most of the cases):
- Drainstop Node 1, which allows the host to continue serving active connection, but disables all new traffic to that host (Node 1)
- Deploy the new version of Sitefinity on Node 1
- Request the page, which will cause Application start. When there is a difference of versions between Sitefinity DLLs and database version the upgrade process will be start. At this moment there are two Sitefinity instances with different versions of Sitefinity (assemblies) and one database with higher version. If there is an application restart the old Sitefinity (LIVE, visible for clients) will be unavailable for the end user. With the new option we will allow the old instance to have successful application start. At the moment this is not possible because of the "Downgrade is not possible" error.

2. We will introduce the option to log DDL (Data Definition Language) statements that alter the database schema (create, alter or drop data structures) during the upgrade process. The statement will show you changes to the database schema. This option will be useful if when an upgrade on environment different from the LIVE is made, before GO LIVE over the fresh database.

Example:
----------------------------------------
Timestamp: 09/09/2015 08:54:33
Message: -- add column for field parentTypeId
ALTER TABLE [sf_meta_types] ADD [parent_type_id] uniqueidentifier NULL
----------------------------------------

3. We are implementing a page which will show the progress of the upgrade during the upgrade.
4. There will be some improvements related to the restarts caused by changes in the structure of the dynamic modules.

Best regards,

Ivelina Ganeva

Sitefinity Team