Deliverables to include in your LMS transition project

I just sent these tweets in succession then I realized I will lose these, and so will those who may be following with an LMS transition in 6 months or a year. (You’re welcome Janel!). Here they are consolidated into a true posting:

1. LMS_Deliverable2

2. LMS_Deliverable3

3. LMS_Deliverable4

4. LMS_Deliverable1


Let me elaborate a bit.

#1 Without the ability to copy a production environment, its configuration and all its courses (database) to a non-production environment, you will never be able to thoroughly test configuration changes, new tools you might add, or system performance under peak loads without impacting your faculty and students.

#2 Please don’t think you can make due without at least a one non-production TEST instance. This is not the place to cut your budget. While end users typically don’t know about this ‘hidden’ environment, your decision not to have one and not to support testing before something is okayed to be a part of your faculty/student tool mix, THAT decision will impact your institution.

#3 In our process just this week we received as a deliverable a word doc capturing all of our discussions around the best way to configure our LMS for Notre Dame. When I received the document I immediately recognized its format as being completely unmanageable as documentation of a ‘known state’ of a system in use. The settings you start with WILL change over time and you need to have a configuration document that is in a format that can be easily reviewed, changed, built-to, and tested-to. You will find as you change your settings, that some of them are dependent on each other, a spreadsheet will allow you to indicate which sets of configuration settings work together and which ones are problematic.

3 thoughts on “Deliverables to include in your LMS transition project

  1. Re: #1 We did the reverse in our migration from Vista 3 to Vista 8 by creating an initial test environment, making the initial configurations there such as the 54 institutions, and clones of that became the ten production databases. Every institution is in every cluster. The institution ids are consistent in every database, which means use of things like use the same configuration file on every cluster.

    Re: #2 We have two tests for checking installs. A test our clients can use to evaluate changes (versions, SPs, HFs, PowerLinks). A training environment for faculty learning to use the system.

    Re: #3 We DBAs prefer keeping the documentation in a wiki. Being able to go back and look at versions over time helps. Our analysts prefer Word docs which give us a headache. Even worse, they pass around a Word doc to come up with the “final” version to put in the wiki.

Comments are closed.