Try Now
More in this section

Forums / Upcoming Features / Upgrade Process Improvements

Upgrade Process Improvements

6 posts, 0 answered
  1. Kali
    Kali avatar
    158 posts
    25 Feb 2009
    04 Sep 2015
    Link to this post
    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.
  2. Steve
    Steve avatar
    3037 posts
    03 Dec 2008
    04 Sep 2015
    Link to this post

    - 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.

  3. betty
    betty avatar
    19 posts
    12 Apr 2011
    04 Sep 2015 in reply to Steve
    Link to this post

    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 

  4. Darrin Robertson
    Darrin Robertson avatar
    105 posts
    18 Jul 2004
    04 Sep 2015
    Link to this post

    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.

  5. Arno
    Arno avatar
    249 posts
    08 Sep 2010
    06 Sep 2015
    Link to this post

    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.

  6. Ivelina
    Ivelina avatar
    4 posts
    11 Apr 2005
    09 Sep 2015
    Link to this post

    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.

    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

6 posts, 0 answered