The best laid schemes

Blog Post created by mdeeprose on Feb 6, 2017

In my previous post I wrote about how we set up a framework for performing Blackboard upgrades. Having set that up I could start planning the upgrade project.




The key risks I was able to identify with an upgrade to 9.1 Q4 2016 was that if we updated to the new responsive interface we would have to update our fantastic Blackboard support website with new screenshots.  Therefore the earlier we could get a test instance of Q4 the better.


Making Plans

So the project plan was to get a dev server upgraded as soon as possible, so that we could assess the impact of changes and document/configure as required.  I decided to plan to update one environment each month from January to March, and then in April hopefully in time for Q2 2017 a new Cumulative Update would be released for Q4 2016.  We could then implement the new CU across all environments and then freeze development to hand over for load testing in May.  Final upgrade would then take place in June.9jT2kTY.jpg


With large gaps between upgrades we would have time to adjust our implementation plans and have enough slack to be able to modify the plan if required as we went on.  Starting the planning so early meant we had the luxury of time for the project to take place.




Collating the technical info

The technical upgrade team met in late December before the Christmas break.  Having sourced all the relevant documentation from Blackboard’s support and user facing sites at these links:


9.1 Q4 2016 Release Notes:

How to upgrade Blackboard: https://en‐


Ol4UnSj.jpgI then created a single PDF which would become our “go to resource” for the first stage of the upgrade project.   I added pages with a team contact list, a reminder of the plan, and a collation of interesting notes from other institutions who had already tried installing 9.1 Q4 2016 that I had found in the mailing lists and on this community site. Creating a single PDF allowed me to add page numbers, and a contents page, and send a copy to the printer to be automatically stapled.  This way the team would have a single document and not innumerable loose sheets of paper.


Here is a copy, with any names/numbers removed.


I gave all team members a print out in the hope that they may read over it during a dull moment during the Christmas break.  I’m not sure if any did, but I spent quite a bit of time reading, highlighting, and making notes.  We had scheduled our first dev server upgrade for 18 January 2017 so I wanted to be sure that I was as prepared as possible.