Enterprise Applications

Change Management


Change Management
A process for limiting the impact of system changes.
Learning Management System (LMS)
Blackboard Learn and its associated services.
Instance Management
DLT currently manages three LMS instances: one is the production system, while the other two are used for system testing, functional testing, and development.
Requests for Change (RFC)
Before changes are made to production LMS components, EAPP will create an RFC at least one week in advance, to allow for testing and discussion. Changes to non-production systems do not normally require an RFC, except for systems that are also hosting production standby systems.
Knowledge Base Articles (KB)
A knowledge base is a published collection of documentation that typically includes answers to frequently asked questions, how-to guides, and troubleshooting instructions.
Change Advisory Board (CAB)
CAB meets weekly to review RFCs and discuss their potential impact on campus operations. Each proposed change is discussed for approval. Issues and changes to the process are discussed by CAB.
Major Releases and Updates
Major releases or updates to any LMS component, such as service packs or similar upgrades, may require a substantial effort. Therefore, a project plan should be completed before non-production implementation and testing.

Advisory Groups

Depending on which learning technologies are impacted by the change, EAPP consults with several advisory groups:

Process Goals

With a goal of increasing campus adoption of our LMS, we all must be committed to:

  • Keeping our systems stable and online.
  • Ensuring system software is current
  • Testing all changes before going into production.
  • Properly communicating with campus by filling all RFC’s at least one week ahead of time.

EAPP will strive to adhere to this process when any changes are needed for CSU Chico's learning technologies, including all environments and services related to Blackboard Learn, SumTotal, Kaltura, Zoom, and LinkedIn Learning, along with other integrated LMS applications and systems.

Maintenance Schedule

Third-party vendors sometimes schedule maintenance windows outside of this process; when that happens, we will do our best to communicate with impacted users before the maintenance occurs.

When DLT is able to control the maintenance schedule, we will strive to ensure maximum stability and availability for all students, faculty, and staff.

The following maintenance windows are typically used for the LMS, and may be leveraged for other systems as well:

  • Overnight maintenance window (no downtime)
    Thursdays, 12 AM to 4 AM PST

  • Morning maintenance window (no downtime)
    Thursdays, 7 AM to 8 AM PST

  • Extended maintenance window (extended downtime)
    Thursdays, 12 AM to 8 AM PST
    Quarterly/Between Terms

From time to time, EAPP will need to schedule maintenance outside of this standard schedule; when that happens, we will be sure to communicate with users.

In addition to the above, our schedule also considers several "blackout windows", where DLT will avoid making system changes in order to maximize stability during critical usage periods:

  • Two-week window at the start of Spring/Fall term, starting one week before the first day of classes
  • Two-week window at end of Spring/Fall term, starting one week before final exams

Maintenance Logs

All service interruptions, including planned or unplanned downtime or other incidents, are logged on DLT's website in order to foster transparency and accountability:

Normal Processes

Non-production install
EAPP will take non-production systems offline to install changes, including patches or other updates.
System testing
EAPP will be primarily responsible for system testing. The length of time spent in testing will depend on the number and impact of proposed changes, with a minimum of one week in testing before moving to production.
Functional testing
TLP will be primarily responsible for functional testing. The length of time spent in testing will depend on the number and impact of proposed changes, with a minimum of one week in testing before moving to production.
Final GO/NO GO decision
EAPP and TLP will report on test completion and make a final decision regarding a move to production.
RFC created
If a go-ahead decision is reached, EAPP will create an RFC. 
Communications and KB articles will be created by TLP.
RFC approved
If CAB approves the RFC, EAPP will schedule any necessary downtime for production maintenance. 
Changes installed
EAPP will install the change, including application shutdown as needed. Refer to the managed hosting maintenance schedule for scheduling information.

Exceptions to normal processes

Emergency patches to resolve security issues, system instability, and similar issues may bypass some or all of this process.
Zero-Day vulnerabilities
Patches to fix zero-day security vulnerabilities will be evaluated on a case-by-case basis.