Enterprise Applications

LMS Change Management

Jump to:

Definitions

Change Management
A process for limiting the impact of system changes.
Learning Management System (LMS)
Canvas, Blackboard Learn and their associated services.
Instance Management
EAPP currently manages two Canvas instances: one is the production system, while the other is used for system testing, functional testing, and development. EAPP also maintains three Blackboard instances: a production system and two testing/development systems.
Requests for Change (RFC)
Before changes are made to production LMS components, EAPP will create an to allow for testing and discussion. Changes to non-production systems do not normally require an RFC, except for systems which are also hosting production standby systems.
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
Most LMS updates happen automattically without any downtime. However, occasionally, 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 change, DLT 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 Chico States's learning technologies, including all environments and services related to Canvas, 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 maintenance scheduling, 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, 12AM to 2AM PST
    Weekly/Monthly

  • Morning maintenance window (no downtime)
    Thursdays, 8AM to 10AM PST
    Weekly/Monthly

  • Extended maintenance window (extended downtime)
    Thursdays, 12AM to 8AM 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 we will avoid making system changes in order to maximize stability during critical usage periods:

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

Normal Processes

See our integrations process page for more information on our change management process.

Exceptions to normal processes

Emergencies
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.