Define operational control before you choose a host
Open-source licensing gives your institution access to source code. It does not assign responsibility for patches, outages, course restoration, accessibility fixes, or integration keys.
Before you select a hosted or campus-run model, assign each responsibility to a named owner. Your institution, a service provider, or both can own a task. Record shared responsibilities. Do not accept a model where both parties assume the other one performs a critical task.
| Operational area | Questions to answer before acceptance |
|---|
| Releases and patches | Which versions are supported? Who approves, tests, deploys, and rolls back a change? |
| Identity and access | Who manages SSO, administrator roles, account recovery, and privileged-access review? |
| Course and file data | Where is data stored? Who can retrieve it? How long is it retained after a course or contract ends? |
| Integrations | Who registers tools, rotates keys, reviews scopes, and removes access when a contract ends? |
| Incidents | Who detects, declares, communicates, contains, and documents an incident? |
| Recovery | What can be restored, from which backup, by whom, and how is the result tested? |
Write the boundary into the operating agreement and test plan. A ticket queue does not assign operational responsibility.
Operate a supported release
An LMS needs a release policy that distinguishes a planned feature update from an urgent security patch. The Sakai project lists its supported release lines. Use the equivalent source for any LMS you evaluate.
For each release, record the following information:
- Application, runtime, database, operating-system, and browser-support versions
- Security advisories and their affected configurations
- Planned maintenance window, owner, approval, rollback condition, and communication path
- Automated smoke tests for login, course access, assignments, gradebook work, and material integrations
- Accessibility and usability regressions that require manual review
Keep a staging environment that includes your identity provider, a realistic course, key integrations, and the current browser support policy. A local login and an empty course cannot validate a production release.
Protect integrations and student data
Learning Tools Interoperability (LTI) launches operate under a security contract between an LMS platform and a tool. The LTI Advantage implementation guide describes how a deployment defines the launch version, parameters, exposed services, and security contract.
Maintain an integration register. For every LTI, SIS, roster, SCORM, video, proctoring, and analytics connection, record the following information:
- Business owner and technical owner
- Data fields and purpose
- Authentication method, scopes, keys, certificates, and rotation date
- Regions, subprocessors, retention, and deletion path
- Failure behavior during a launch, grade return, roster sync, or course copy
- Offboarding procedure and evidence that access was removed
Use least privilege. A tool that needs a course context does not automatically need gradebook write access or a full institutional roster. Re-check registrations when the LMS, tool, or institutional policy changes.
Test complete accessibility processes
Accessibility requires ongoing operational work. WCAG 2.2 requires conformance across a complete process. An LMS workflow does not conform if a required step fails. WCAG 2.2 conformance requirements define this scope.
Test representative processes from start to finish:
- Sign in with the institution’s identity flow and recover access.
- Create, copy, publish, and archive a course.
- Upload and manage course materials.
- Complete an assignment, assessment, or discussion with the keyboard and assistive-technology combinations in your support policy.
- Grade, provide feedback, and return grades through integrated tools.
- Request and receive support.
Run automated checks for common defects. Then use a keyboard and assistive technology to complete the same workflow. Longsight’s Playwright and axe testing practice describes one way to combine both forms of evidence.
Practice recovery before an incident
A backup policy is incomplete until you restore a representative service and examine the result. Restore a course, files, submissions, grades, permissions, integrations, and audit records. Confirm that the restored environment cannot overwrite active production data.
Document the following facts from each exercise:
- Backup source, encryption, retention, and access boundary
- Restoration owner and required approvals
- Time to locate the backup, restore it, and make the service usable
- Data loss between the selected backup and the exercise start
- Differences found after restoration and how you resolved them
Keep administrative and security events available for investigation. The OWASP logging guidance recommends recording administrative functions and security-configuration changes. Limit access to logs because LMS events can contain sensitive student information.
Plan migration and exit as normal operations
An exit plan protects institutional control during a hosting change, a platform migration, or an incident that affects the provider. Define the export format, scope, timing, cost, and assistance before the contract begins.
At minimum, test an export of the following data with a representative course:
- Course structure, pages, assignments, assessments, rubrics, discussions, and learning outcomes
- Files, media, links, and accessibility alternatives
- Enrollments, roles, groups, and course dates where policy permits
- Gradebook records, feedback, and submission evidence, subject to retention requirements
- Integration registrations, configuration, documentation, and audit records
Import the export into the intended destination or an independent inspection environment. Track loss, transformation, and manual repair separately. Longsight’s Sakai SCORM runtime work and Canvas import work show why content-transfer tests need explicit boundaries and diagnostics.
Run institutional acceptance tests
Suppliers can provide useful test reports. Only your institution can confirm that an LMS works with its identity system, support model, courses, policies, and accessibility requirements.
Use the following acceptance sequence:
- Define the operational responsibilities and success criteria.
- Load representative courses, people, roles, and integrations into a controlled environment.
- Execute normal teaching, learning, administration, accessibility, and support workflows.
- Simulate a failed launch, a permission error, an unavailable integration, and a recovery exercise.
- Record defects, owner, severity, workaround, remediation date, and retest result.
- Repeat the relevant tests after material releases or configuration changes.
Keep the acceptance suite under institutional control. Use it for procurement, change approval, service review, and a future exit.
