Our Summer 2016 upgrade was successful, but running an upgrade project from start to finish in eight weeks had been a stressful experience. We had only this short period of time due to local resourcing issues. To improve this going forwards I wrote a paper stating how upgrades would be controlled in the future.
As we know, new versions of Blackboard Learn are released every other quarter. Namely the Q2 and Q4 releases.
Our upgrade window is always around late June. A Q2 release in April is likely to be too short notice for us to upgrade to in June.
Cumulative Updates (CU) are meant to be released every 1 to 2 months. Experience shows that when a new version of Blackboard is released, a CU containing bug fixes is often released for previous versions at about the same time.
Therefore the paper states that every June upgrade window we will upgrade to the Q4 release of the previous year, with the latest Cumulative Update possible.
I met with team leaders/reps from our Linux server team, Oracle DBA team, and Applications Management Teams, talked through the approach with them and sort feedback. By the end we had an agreed practice that we could build our next upgrades upon.
This is a very simple practice, and I know many other institutions have similar arrangements. The benefit to us was that we could have this practice formalised and made known to the technical teams who support our local upgrades so that they can schedule the appropriate resource in advance.
TL;DR: made a plan for regular upgrades; obtained buy-in to the plan in advance.