This makes it hard to estimate how much time will be involved in the upgrading process.
Every site is different, so I understand that it's impossible to give an exact estimation that covers all cases, but I would love to hear your experiences...
For small, simple websites as well as for the more complex, big ones with lots of pages and packages in use.
Just to get a better feeling about what sounds realistic.
How much time do you reserve for upgrading to a new version?
Did you manage to upgrade within
a few minutes
hours
days?
Which tools and setups made upgrading much easier and faster?
What parts of the upgrade were time-consuming for you? (eg. comparing/merging config files, upgrading other packages, custom code, ...?)
My experience has always been good when it comes to doing upgrades but it really depends on how you or your dev team have built the site.
Hindsight is a wonderful thing but there are some basic steps that you can take when building sites that I have found make upgrades a smoother experience.
Firstly, invest time in source controlling (SC) your project and understanding what you need to put under SC and what can be excluded.
Secondly, try to avoid adding custom packages and see if what you are trying to achieve is possible using the core. If you do need to add packages then I always pick ones which look like they will be adopted into the core or that are created and managed by well respected community members. If possible review the code, most packages that are worth installing will have a Github repo so you can review the code, commits and look at any issues. The update frequency and history of the repo will usually give you a good idea of how likely it is to last the test of time.
Lastly, where possible I only use packages that are available via Nuget. Although this is more a personal preference and not something that is a hard rule.
My go to packages are
DiploTraceLogViewer
Diplo.AuditLogViewer
nuPickers
Our.Umbraco.CoreValueConverters (now not need)
Our.Umbraco.DocTypeGridEditor
Our.Umbraco.NestedContent
uSync
Putting the above aside on a practical level I have just today upgraded a site of 1500 pages from 7.4.3 to 7.6.1.
The upgrade took about 3 hours using only Visual studio 2017 and Git (within the IDE). Most of the time was spent running through test scripts after merging the config files and changing some code to remove property values converters package. This can now be done in the core. I believe nested content is going into the core as well maybe in 7.7?
I also needed to use Ready Roll in VS 2017 before and after the upgrade to generate migrations scripts for the DB as our DBA does not allow for applications to use accounts that can change DB schemas.
David, I'd be interested to hear what you feel should and shouldn't be in SC, I'm just looking at this for a site I'm working on and some infor would be great.
Thanks
I have included an example of our .gitignore file to show the type of things we exclude.
I also always source control umbraco, which i know technically you don't need to do as it's already SC but i like to see what has changed when i do an upgrade. In reality its normally only the config folder than you are going to need to worry about. I also let configs get overwritten during the upgrade and then merge back my customisation's.
I am new to Umbraco, but coming from the opposite end of the pool as D Hutson's post, maybe it will be worthwhile to hear my experience.
My organization produces very simple sites that only utilize the core/out-of-the-box functionality of Umbraco. We have some custom Razor code but that is about it. Upgrading usually looks something like this:
5 minutes to backup our Umbraco DB and file structure
15 minutes to perform a manual update
45 minutes of trouble shooting
10 minutes to restore the backup and perform the update correctly
I feel like each time we upgrade, the process is easier and quicker as we learn the caveats and nuances of Umbraco.
Obviously Umbraco is a robust solution that is built to be malleable, so all I can say is there must be some seriously different use-cases out there (e.g. ours vs D Hutson). Upgrade time probably varies drastically depending on your project and experience level.
To help clarify why my approach is a bit more complex than your average site. I work for a government regulator. As such, all IT processes including application deployments run under the ITIL framework and all changes have to go through a change management process.
This means I release my code through a number of environments before production and therefore the build and deployments have to be automated and repeatable. Once the code leaves development it can not be tweaked or changed in the back office. Production is purely used for content creation and management read-only if you like.
I have found that following the structured approach listed above helps with quick successful releases. To date we have had no outages or YSOD following this approach.
The site runs our corporate intranet and also surfaces some business applications inside umbraco and some custom knowledge management solutions for our call centres.
Prior to this i worked with Umbraco running on Azure (in the days before Umbraco Cloud). There I was in control of all elements of the build and followed a more similar workflow to Joshua.
Despite the constraints I do believe that in the long run it's quicker and more robust.
Although the topic typically doesn't have one single right answer, I selected Davids answer as a solution so others know that this topic got useful responses.
Still, if others like to share their thoughts even ... or actually especially ... when upgrading did not go as you had expected, please let it know so we all can learn from it!
Reserving time for upgrading to Umbraco 7.6
I have seen several comments about the upgrade process of Umbraco saying that, in general, it can be done quite smoothly.
But so far, there are always some manual adjustments and merging needed for upgrading as far as I understand from the documentation in:
This makes it hard to estimate how much time will be involved in the upgrading process.
Every site is different, so I understand that it's impossible to give an exact estimation that covers all cases, but I would love to hear your experiences... For small, simple websites as well as for the more complex, big ones with lots of pages and packages in use.
Just to get a better feeling about what sounds realistic.
How much time do you reserve for upgrading to a new version?
Did you manage to upgrade within
Which tools and setups made upgrading much easier and faster?
What parts of the upgrade were time-consuming for you? (eg. comparing/merging config files, upgrading other packages, custom code, ...?)
Hope to see your experience with upgrading!
Hi Micha
My experience has always been good when it comes to doing upgrades but it really depends on how you or your dev team have built the site.
Hindsight is a wonderful thing but there are some basic steps that you can take when building sites that I have found make upgrades a smoother experience.
Firstly, invest time in source controlling (SC) your project and understanding what you need to put under SC and what can be excluded.
Secondly, try to avoid adding custom packages and see if what you are trying to achieve is possible using the core. If you do need to add packages then I always pick ones which look like they will be adopted into the core or that are created and managed by well respected community members. If possible review the code, most packages that are worth installing will have a Github repo so you can review the code, commits and look at any issues. The update frequency and history of the repo will usually give you a good idea of how likely it is to last the test of time.
Lastly, where possible I only use packages that are available via Nuget. Although this is more a personal preference and not something that is a hard rule.
My go to packages are
Putting the above aside on a practical level I have just today upgraded a site of 1500 pages from 7.4.3 to 7.6.1.
The upgrade took about 3 hours using only Visual studio 2017 and Git (within the IDE). Most of the time was spent running through test scripts after merging the config files and changing some code to remove property values converters package. This can now be done in the core. I believe nested content is going into the core as well maybe in 7.7?
I also needed to use Ready Roll in VS 2017 before and after the upgrade to generate migrations scripts for the DB as our DBA does not allow for applications to use accounts that can change DB schemas.
Hope this offers some insight.
Thanks David,
This is definitely the kind of response I was hoping for!
Very useful!
Hope that there are more people who like to share their experiences this way!
David, I'd be interested to hear what you feel should and shouldn't be in SC, I'm just looking at this for a site I'm working on and some infor would be great. Thanks
Hi Owain
I have included an example of our .gitignore file to show the type of things we exclude.
I also always source control umbraco, which i know technically you don't need to do as it's already SC but i like to see what has changed when i do an upgrade. In reality its normally only the config folder than you are going to need to worry about. I also let configs get overwritten during the upgrade and then merge back my customisation's.
I am new to Umbraco, but coming from the opposite end of the pool as D Hutson's post, maybe it will be worthwhile to hear my experience.
My organization produces very simple sites that only utilize the core/out-of-the-box functionality of Umbraco. We have some custom Razor code but that is about it. Upgrading usually looks something like this:
I feel like each time we upgrade, the process is easier and quicker as we learn the caveats and nuances of Umbraco.
Obviously Umbraco is a robust solution that is built to be malleable, so all I can say is there must be some seriously different use-cases out there (e.g. ours vs D Hutson). Upgrade time probably varies drastically depending on your project and experience level.
To help clarify why my approach is a bit more complex than your average site. I work for a government regulator. As such, all IT processes including application deployments run under the ITIL framework and all changes have to go through a change management process.
This means I release my code through a number of environments before production and therefore the build and deployments have to be automated and repeatable. Once the code leaves development it can not be tweaked or changed in the back office. Production is purely used for content creation and management read-only if you like.
I have found that following the structured approach listed above helps with quick successful releases. To date we have had no outages or YSOD following this approach.
The site runs our corporate intranet and also surfaces some business applications inside umbraco and some custom knowledge management solutions for our call centres.
Prior to this i worked with Umbraco running on Azure (in the days before Umbraco Cloud). There I was in control of all elements of the build and followed a more similar workflow to Joshua.
Despite the constraints I do believe that in the long run it's quicker and more robust.
Thanks all for your responses,
Although the topic typically doesn't have one single right answer, I selected Davids answer as a solution so others know that this topic got useful responses.
Still, if others like to share their thoughts even ... or actually especially ... when upgrading did not go as you had expected, please let it know so we all can learn from it!
is working on a reply...