Open source LMS for education

Open source LMS for education: why student records change the build

An academic institution deciding where its learning management system runs is, in practice, deciding where student records live. Course submissions, grades, feedback, discussion posts, login activity and, at schools, data about minors all sit inside the LMS. Under FERPA, the US rules in 34 CFR Part 99 apply to any educational agency or institution that receives funds from a program administered by the US Secretary of Education (34 CFR 99.1), and many of the data points an LMS holds fall within the definition of education records. That makes access control, disclosure logging and the partner contract shape the design more than any feature list does. Before comparing platforms, confirm with counsel which LMS data elements your institution treats as education records and which sit outside that definition.

On platforms, the short answer depends on how the institution teaches. Moodle fits broad academic use, with the widest plugin ecosystem and core authentication options including LDAP, LTI, OAuth 2 and Shibboleth. Open edX fits best where MOOC-style or course-catalog delivery dominates, since its Studio and LMS split is built for that model. Canvas, which is licensed under AGPL-3.0, suits an institution that accepts that license and has a partner able to support the code. None of these platforms is compliant by default. FERPA compliance comes from how you configure roles, restrict school official access, log disclosures and write the contract, so treat each platform as a starting point for that work.

Each choice carries a contract question. A contractor may receive education records as a school official only if it performs a service the institution would otherwise use employees for, works under the institution's direct control for the use and maintenance of the records, and follows the redisclosure limits in 34 CFR 99.33(a) (34 CFR 99.31(a)(1)(i)(B)). Ask any hosting or support partner to show how it limits its own staff access, how it supports the disclosure record that FERPA requires under 34 CFR 99.32, and how it handles a parent's inspection request within the 45-day limit in 34 CFR 99.10(b). Keep the answers in the statement of work so they are enforceable, not only described in a sales deck.

Which education rules shape the LMS build

This table maps the US education and accessibility rules most likely to shape a self-hosted LMS to the build decisions they force: roles, logging, retention and hosting. Read each row as a requirement, the evidence an assessor or counsel will ask for, and what your platform team must configure or contract for. Confirm applicability with counsel, since these rules depend on your institution type, funding and learner ages.

Requirement	Source	Build meaning
Outside party as a school official	34 CFR 99.31(a)(1)(i)(B): contractor may receive education records only for a service staff would otherwise perform, under direct institutional control, with redisclosure limits	Hosting or support partner needs a written agreement, named administrators, use limited to the service, and no reuse of learner records for its own purposes
Role-based access to student records	34 CFR 99.31(a)(1)(ii): reasonable physical or technological access controls so school officials see only records with a legitimate educational interest	Map LMS roles to course and program scope, restrict gradebook and profile fields by role, and test that instructors cannot reach unrelated learners
Disclosure logging	34 CFR 99.32: record each request for and disclosure of personally identifiable information, with the parties and their interests, kept as long as the records are kept	Enable and retain audit logs for exports, report downloads, API pulls and third-party LTI launches, and keep the disclosure log with the records
Inspection request timing	34 CFR 99.10(b): comply with a parent or eligible student inspection request within a reasonable period and no more than 45 days	Build a report that pulls a learner's grades, submissions and access history quickly, and confirm who in the operations team can run it under the 45-day limit
Enforcement exposure	34 CFR 99.67: the Secretary may withhold payments, issue a cease and desist order or end funding eligibility for non-compliance	Treat FERPA controls as a platform requirement tested before go-live, not a policy document added later
Web and mobile accessibility (ADA Title II)	28 CFR Part 35 Subpart H: WCAG 2.1 Level AA; compliance dates April 26, 2027 (50,000 or more people) and April 26, 2028 (smaller entities and special districts) per the April 20, 2026 interim final rule	Audit theme, plugins and course templates against WCAG 2.1 AA, decide who remediates instructor-made content, and set a dated plan that fits your deadline
Children under 13 (COPPA)	16 CFR 312.8 and 312.10: written information security program with a coordinator and at least annual risk assessments; retention only as long as reasonably necessary, with a written retention policy and deletion timeframe	For K-12 or child-facing courses, document the security program, set account and submission deletion periods, and confirm which third-party tools collect child data
MFA and FTC notification (GLBA Safeguards Rule)	16 CFR 314.4(c)(5) and (j): multi-factor authentication for anyone accessing information systems, and FTC notice within 30 days for events affecting at least 500 consumers; Title IV institutions must comply under their Program Participation Agreement	Enforce MFA for staff and admin accounts, include the LMS in the written security program and incident runbook, and confirm the 30-day notice workflow with counsel

Which LMS fits which academic model

A general university or college usually needs a broad course catalog, many concurrent courses each term, integration with a student information system, and a platform that a central IT team can keep current for years. Moodle fits this model well. Its code is GPL-3.0 licensed, it is maintained by Moodle HQ, and it can be self-hosted or run as managed hosting. Moodle 5.3 is the designated next long-term support release, with bug fixes until October 4, 2027 and security fixes until October 1, 2029, which gives planners a defined window to align with budget cycles.

Upgrade prerequisites: Sites must run Moodle 4.4 or later to upgrade to 5.3, and 5.3 requires 64-bit PHP 8.3 or later with PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later.
Core authentication: Core ships LDAP, OAuth 2, Shibboleth, LTI and web services plugins, which cover most campus directory patterns.
Learning outcomes: Moodle 5.3 adds a learning outcomes feature that should be tested against the institution's program assessment process.
Theme change: The Classic theme is removed from core in 5.3, so custom styling and theme work need review before cutover.
Release notes: Read the Moodle 5.3 release notes with the registrar and academic technology teams before scheduling work.

Confirm with the vendor or partner which student information system connector your registrar requires, how grade passback is handled, and whether every plugin you depend on has a release for 5.3.

How the LMS connects to the student information system and sign-in

The LMS depends on four data flows that should be designed before any course is built. Enrollment and roster sync brings students and instructors in from the student information system (SIS), grade return sends final marks back, identity handles sign-in, and LTI tool launches pass learners from the LMS into external tools with a trusted context. Each flow needs an owner, a direction, a schedule and a failure procedure. Ask your SIS vendor which API or export options it offers, whether it supports push or only scheduled file drops, and how it marks withdrawals and changes to sections. Those answers decide whether roster sync is a nightly job or a near-real-time integration, and they set the boundary of the build.

Sign-in options differ by platform. Moodle core ships authentication plugins for manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2, Shibboleth and web services, and SAML 2.0 is typically added through a plugin such as the SAML2 Single sign on plugin. Open edX third-party authentication supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, with older provisional support for CAS and SSL client certificates. Confirm that your identity provider's attribute release supports the student ID and role attributes the LMS needs, and decide whether the SIS or the identity provider is the source of truth for enrollment status, because the two will drift if both are allowed to create accounts.

Test term rollover and drop dates before go-live, not after the first week of classes. Run a full cycle in a non-production environment: load a new term, apply a mid-term drop, reactivate a student who was re-enrolled, and change a section's instructor. Check that grade return writes to the correct course and that accounts for students who leave are suspended rather than deleted, so their records remain available for retention. Document who approves a manual roster correction and how long it may take to appear in the LMS. This test script is the single most useful artifact to request from any implementation partner.

Deployment patterns for FERPA-bound hosting

An institution hosting a Moodle or Open edX platform with student records must decide who runs the servers, who can reach administrative functions, and where evidence lives. The four patterns below differ mainly in who holds those keys, so each card asks the same questions about access, logs, backups and exam-period capacity.

Institution-owned data center or cloud account

The school or university runs the servers, network and database in its own data center or cloud account. Administrative access sits with the institution's staff, which keeps direct control over education records but puts the burden of patching, backups and peak capacity on its own team. Ask who holds root and database credentials, whether logs ship to a central store the institution controls, and how exam-period scaling is provisioned before the term starts. Confirm the team can sustain on-call coverage during exam weeks.

Partner-operated environment under institution control

A hosting or support partner operates the platform inside the institution's own cloud tenancy or data center, with the institution holding the accounts and encryption keys. This is the pattern in which a partner may act as a school official, provided it performs a service the institution would otherwise use staff for and remains under the institution's direct control. Put named administrative access, session recording and log access in the contract, and confirm the partner can produce a disclosure log on request.

Managed hosting from a Moodle partner

A Moodle partner or MoodleCloud operates the instance on infrastructure the vendor chooses, often in a region the institution does not select. Administrative access is shared between the provider and the institution's administrators, so the contract must state where data is stored, who can open support sessions, how long logs are retained, and which subprocessors touch learner data. Ask for written backup encryption standards and restore testing results, and confirm the exam-period capacity commitment in the order form rather than assuming it.

Separate staging for upgrades

A staging environment mirrors production configuration, plugins and a sanitized or synthetic copy of the database, so each Moodle upgrade or theme change is tested before it reaches learner data. Staging needs its own administrative accounts, logs and backups, and it must not hold live student records unless it is protected to the same standard. Moodle 5.1 requires the web server document root to point to the new public directory, and a staging check should confirm that before cutover. Verify the PHP and database versions in staging match the target production versions.

Backups, encryption and retention

Backups of the database, file store and course content must be encrypted, stored where the institution controls the keys, and retained for a period the records schedule defines. FERPA requires disclosure records to be kept for as long as the education records are kept, so backup retention and log retention must be planned together rather than set separately. Ask the operator to document backup frequency, the restore procedure, who can restore individual student records, and how a deleted record is removed from older backups.

Logs, access reviews and exam-period capacity

Web, database and Moodle event logs should live in a store that the institution can query, with access limited to named roles and reviewed on a schedule. Exam periods concentrate logins and quiz attempts into short windows, so the team should load-test the platform against expected concurrency and confirm database engine versions. Moodle 5.3 requires PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, so confirm which engine the chosen pattern supports. Ask for a load-test report and a written capacity plan for the heaviest exam week.

Scaling the LMS for exam periods and enrollment peaks

Sizing an LMS for an institution starts with the load pattern, not the average day. Traffic on a university or school LMS clusters around a few predictable moments: term start when students log in to claim their courses, quiz and exam windows when hundreds or thousands of learners open a timed assessment at the same minute, and grade release days when students refresh gradebooks at once. Each spike stresses different parts of the stack. Quizzes write answers continuously to the database, grade releases read large gradebook tables, and term start stresses authentication and enrollment sync. Before any hosting decision, ask your registrar, assessment office and IT team to document these peaks by hour and by course type, then carry those concurrency figures into the sizing worksheet from your LMS requirements checklist. Do not size from total enrollment alone, because a 40,000-student institution may never see more than a fraction of them active at once.

Database and cache choices follow from that profile. Moodle 5.3 requires PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, so confirm which engine your team can tune, back up and patch under load, and confirm the PHP version your hosting image supports. On Open edX, the edx-platform repository states that multi-node deployments need a shared Django cache backend such as Redis or Memcached, so a deployment that runs several LMS application nodes without a shared cache will not behave consistently across them. Ask your implementation partner to show how sessions, cached course content and gradebook reads are shared across nodes, how the cache is sized, and what happens to in-progress quiz attempts if a node or cache instance fails during a timed exam.

Load testing is the control that turns these choices into evidence. Run a scripted test before each term and before each major exam window, using realistic learner paths: login, course navigation, quiz start, answer submission, and gradebook view, with ramp-up profiles that mirror the peaks you documented. Measure response times, error rates and database lock behavior, and repeat the test after every plugin, theme or LTI tool change, since third-party code is a common source of slow queries. Agree in writing who owns the test environment, who approves a go or no-go decision, and which freeze dates apply to course changes during exam weeks. Treat the results as the input for the next capacity change, and keep them with your change records so auditors and academic leaders can see how the platform was prepared.

Rollout phases for a university or school LMS

This sequence moves a school or university from data and FERPA scoping to a supported, upgradable LMS, with each phase ending in a named output that the next phase depends on. Sign-off gates keep records, identity and accessibility decisions from being deferred until after launch.

Map data flows and FERPA roles
The institution's privacy or registrar lead and the implementation partner list every data flow: enrollment feeds from the student information system, grades returned to it, identity attributes, third-party tools and any hosting or support contractor with access. Each party is classified as an institution employee, a school official under direct control, or a separate party, using the FERPA school official conditions in 34 CFR 99.31. The step closes with a signed data flow register and a role matrix that a counsel or privacy officer has reviewed. Confirm the institution's own FERPA obligations with counsel before work starts.
Decide platform and design hosting
The team chooses between Moodle, Canvas or Open edX against the requirements list, and documents why. For Moodle, the decision includes the LTS line, the supported database versions for that release and the web server layout, including the /public document root from Moodle 5.1 onward. The hosting design covers environments (production, staging, test), backups, identity network paths and how peak load will be served. The output is an approved architecture decision record and a hosting specification that the institution's IT security team has accepted.
Integrate SIS and identity with test terms
The partner builds the enrollment, roster and grade-passback connections to the student information system, and connects single sign-on through the identity provider the institution already runs, such as SAML 2.0 or LDAP. Integrations are tested with a synthetic term containing test students, course sections, mid-term enrollment changes and withdrawals. Deprovisioning is tested as carefully as provisioning, because access to education records must follow enrollment status. The output is a test log that shows every scenario passed or has a recorded fix.
Migrate content and gradebooks with reconciliation
Course content, question banks, gradebook history and certificates are migrated from the legacy system in batches. After each batch, the team reconciles record counts, grade totals and enrollment links against source extracts, and a registrar sample checks a set of learners by hand. Discrepancies are logged, corrected at source where possible and re-run. The output is a reconciliation report signed by the registrar or academic records owner, with a list of any content deliberately retired.
Audit theme, plugins and course templates
The accessibility reviewer checks the theme, every installed plugin and the standard course templates against WCAG 2.1 Level AA, which the ADA Title II rule requires for covered public institutions. Findings are ranked by learner impact, and the team decides which items are fixed in the theme or plugin and which are assigned to course owners as content remediation. The output is an accessibility audit report, a remediation backlog with named owners and a template set that passes the agreed checks. Ask the partner who owns remediation of instructor-made content before the audit starts.
Load test for exam periods
The team models the highest expected concurrent use, such as final exam windows and enrollment days, and runs load tests against the staging environment that matches production. Tests cover quiz submission, file upload, gradebook views and login spikes, and the team watches database, cache and PHP or application server behavior. Bottlenecks are fixed and the test is repeated until the results meet the targets the institution set. The output is a signed load test report and a documented exam-week runbook.
Run a pilot with one course cohort
A single course cohort, selected with the faculty sponsor, uses the platform for a full assessment cycle while support staff record every ticket and workaround. The pilot checks enrollment accuracy, grade return timing, mobile use and the accessibility fixes in real use. Feedback is triaged into fixes before cutover and fixes that must wait. The output is a pilot closure report with go or no-go criteria marked as met or not met, approved by the sponsor.
Cut over and set retention
The team schedules the cutover outside a high-stakes assessment window, freezes legacy edits, runs the final migration delta and switches enrollment and single sign-on to the new platform. Retention rules are configured for education records, disclosure logs and course data, following the institution's records schedule and the FERPA recordkeeping requirement in 34 CFR 99.32. The output is a cutover checklist signed off, a documented retention schedule and a read-only archive of the legacy system for the agreed period.
Set the upgrade calendar to LTS dates
The partner and the institution agree an upgrade calendar tied to the vendor's published support dates, so the platform stays on a release that receives security fixes. The calendar covers test upgrades in staging, plugin compatibility checks, theme and accessibility regression tests and a change window that avoids assessment periods. For Moodle, the calendar follows the published LTS and security support dates. The output is an approved upgrade plan with named owners and a standing review date for each release.

Evidence auditors and compliance offices ask for

This table lists the records a compliance office or auditor typically asks to see for a self-hosted LMS serving students, what each record proves and which platform component or internal process produces it. Use it to decide what to design into the build from day one, since evidence that was never collected cannot be recreated later. DeployOpen prepares these artifacts, but independent auditors and certification bodies issue any attestation.

Evidence	What it proves	Produced by
FERPA disclosure log	Each request for and disclosure of personally identifiable student information, with the parties and their legitimate interest, kept for as long as the records are kept (34 CFR 99.32)	Logging and reporting configured on the LMS and any integration layer, plus a documented request procedure
Role and access review records	School officials see only the education records they have a legitimate educational interest in (34 CFR 99.31(a)(1)(ii))	Role assignments exported from Moodle or Open edX, reviewed and signed off by the data owner on a set schedule
Service provider contract terms	A hosting or support partner acts as a school official under the institution's direct control and follows redisclosure limits (34 CFR 99.31(a)(1)(i)(B))	Signed contract and data processing terms held by the institution, referenced in the partner's support documentation
Data retention and deletion records	Student and minor data is kept only as long as needed and deleted on a documented timeframe, including children under 13 (16 CFR 312.10)	Written retention schedule, deletion job logs and sign-off for purges of inactive accounts and course archives
Accessibility audit reports for theme and plugins	Custom themes and third-party plugins were tested against WCAG 2.1 Level AA, the standard referenced by the ADA Title II rule	Independent accessibility testing of the theme, plugin inventory and remediation tickets; instructor content owned by the institution
Backup and restore test results	Backups of the database, course files and configuration can be restored within the recovery targets the institution set	Scheduled restore tests run in a non-production environment, with dated results and the names of the people who ran them
Upgrade records against support windows	The platform version in use is still within its security support period, such as Moodle 5.3 with security fixes until October 1, 2029, or the current Open edX named release	Change tickets, test sign-off and version inventory kept by the operations team against the vendor release calendar
MFA configuration for Title IV institutions	Multi-factor authentication is required for anyone accessing information systems that hold student financial and education data under the GLBA Safeguards Rule (16 CFR 314.4(c)(5))	Identity provider policy, LMS authentication settings and exported enrollment reports for administrator and staff accounts

Questions education buyers ask before hiring a partner

What drives the cost of an academic LMS project?

Moodle, Canvas and Open edX have no license fee, so the cost is the work around the platform: hosting sized for peak load, setup and theming, integration with the student information system and identity provider, content migration, upgrades and support. Setup and integration are one-time costs in most projects, while hosting, upgrades, plugin maintenance and support recur every year. The biggest cost drivers are the number of systems to integrate, the volume and format of courses to migrate, the amount of custom theming, and how many exam periods must be handled without degraded service. Ask any partner for a quote that separates one-time work from recurring items, names who is paid for each task (the partner, your hosting provider, or a plugin vendor), and states what is excluded.

How long does a university LMS migration take, and what sets the duration?

The duration depends mostly on scope rather than on the platform choice alone. The main variables are the number of courses and the state of their content, how many integrations must be built and tested (identity, SIS, grade export, LTI tools), whether the institution needs a pilot term before full cutover, and how much of the calendar is blocked by enrollment, exam and accreditation periods. Migrations usually stall on data quality and approvals, not on technical installation. Ask for a written schedule with milestones, a named list of dependencies on the institution's side, and a cutover window that avoids the start and end of a term.

What must our institution provide before a partner starts?

A partner can build much of the platform, but several inputs must come from your institution. These typically include read or integration access to the student information system and identity provider, a named business owner who can approve grade and enrollment rules, a legal or privacy review of the data processing terms, and a group of faculty and staff testers who can work through real courses before cutover. Ask the partner to list every input with an owner and a date in the statement of work. Missing SIS access or late testers are among the most common reasons a fixed-scope timeline slips.

Can a school run a self-hosted LMS internally without a partner?

Yes, some institutions run Moodle or Open edX with their own staff, but the work does not stop after launch. Internal teams need skills in web server and database administration, PHP or Python operations, identity federation, backup and restore, and security patching. The maintainers of Open edX recommend running it in production through a service provider or with Tutor, and note that bare-metal installation is complex and receives limited community support. Assess your team against the upgrade calendar, the on-call expectations during exam periods, and staff turnover. A partner can cover the gap for a defined period or on a retainer.

Who fixes accessibility problems in instructor-made course content?

Responsibility is split between the platform, the theme and plugins, and the content authors. The platform team usually owns the accessibility of the LMS interface, the theme and any third-party plugins, and should audit them against WCAG 2.1 Level AA. The institution owns the remediation of instructor-made content, such as documents, videos, captions and images, because faculty create it. The ADA Title II rule requires state and local government web content and mobile apps to meet WCAG 2.1 Level AA, with compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts, according to the DOJ interim final rule published April 20, 2026. Ask the partner to define the audit scope, the remediation workflow for content, and who signs off before you rely on it.

How do Moodle LTS and Open edX release timing affect our plan?

Release timing sets how often the platform must be upgraded, so it belongs in the plan from day one. Moodle 5.3 is designated the next long-term support release, released on October 5, 2026, with bug fixes until October 4, 2027 and security fixes until October 1, 2029, and Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Open edX supports only its latest named release, Verawood, and the next releases, Willow and Xylon, are listed for December 2026 and June 2027. Because Open edX cannot support more than one release at a time, plan for regular upgrades. Ask the partner which release you will start on, how upgrades will be tested against your plugins and integrations, and who carries the upgrade cost each cycle.

Can a hosting or support partner act as a school official under FERPA?

A contractor can receive education records as a school official only under specific conditions. The institution must determine that the party performs a service it would otherwise use employees for, that the party is under the institution's direct control for the use and maintenance of the records, and that it follows the redisclosure limits in 34 CFR 99.33(a), as described in 34 CFR 99.31(a)(1)(i)(B). The institution must also use reasonable access controls so school officials see only the records in which they have a legitimate educational interest, under 34 CFR 99.31(a)(1)(ii). Put these conditions into the contract, define role-based access and disclosure logging, and have your counsel review the terms. DeployOpen prepares systems and controls for these reviews but does not issue legal opinions or compliance certifications.

Questions to put to an LMS implementation partner

Start with the FERPA terms, because they decide whether a partner can touch student records at all. Under 34 CFR 99.31(a)(1)(i)(B), an outside contractor can receive education records as a school official only if it performs a service the institution would otherwise use employees for, works under the institution's direct control, and follows the redisclosure limits in 99.33(a). Ask the partner to show its school official terms in writing, to name which people can reach student data during support, and to explain how it enforces role-based access so that staff see only records tied to a legitimate educational interest. Then ask how disclosure logs are exported. FERPA requires a record of each disclosure, kept for as long as the records are kept, so ask for the export format, the fields captured and a sample file pulled from a test environment.

Next, ask how integrations and load are proven before term start. Request a test plan that covers the student information system feed, LTI tool launches and grade passback, with the exact Moodle or Open edX configuration and the authentication path (for Moodle, the enabled plugins such as LDAP, LTI, Shibboleth or SAML2; for Open edX, the third-party identity providers). Ask for the peak concurrency figure the partner used, how it was generated, and which exam-period scenarios were run, including load tests and a rollback plan if a test fails. Ask who owns each test result and where it is recorded. Request the reference architecture and a written scope before any work starts, and confirm that the scope lists the responsibilities for hosting, backups and support.

Finally, ask about upgrades, accessibility and deletion. For Moodle, ask how the team will plan a move to 5.3 LTS, which has security support until 1 October 2029, and how it will check the PHP and database versions named in the release notes and the change to the /public document root. For Open edX, ask how it handles the rule that only the latest named release is supported. On accessibility, ask who fixes defects in third-party plugins and theme code, and whether that fix is in scope or billed separately. On deletion, ask how learner data is removed at the end of the retention period, which systems are covered (backups, analytics stores, logs), and how the partner confirms the deletion to the institution in writing.

How DeployOpen scopes an education LMS

This sequence turns an institution's LMS requirements into a written, fixed scope with a clear handover, so the platform, integrations and evidence are agreed before any build work begins. It also sets up the ongoing support model that keeps the platform current after launch.

Confirm the platform choice and requirements
DeployOpen reviews the institution's learner numbers, course types, content formats, identity sources and student information system with the academic, IT and privacy teams. Together you decide whether Moodle, Canvas or Open edX fits the teaching model, using the institution's own requirements rather than a default. The output is a requirements register that names each integration, data flow and accessibility target, and records who approves each decision.
Agree the written scope and deliverables
DeployOpen drafts a fixed-scope proposal that lists the platform version, hosting location, integrations, migration work, theming, testing, documentation and handover items, with the responsibilities of each party. The institution's legal, privacy and procurement contacts review the contract terms, including how a support partner would be treated for student records. Work starts only after the scope, deliverables and timeline are signed off in writing.
Confirm the hosting and data boundary
The team documents where the platform will run, whether in the institution's own cloud account, a data center or a provider the institution selects, and who holds administrative access. It records which records stay inside that boundary and which third-party plugins or AI and video services would receive personal data. The output is an architecture and data flow diagram that the institution's privacy office can review before any student record is loaded.
Build, harden and configure the platform
DeployOpen installs the agreed platform version inside the institution's infrastructure, configures database, cache and web server settings, sets up role-based access, and hardens the server and application layers. Authentication is connected to the institution's identity provider, and gradebook, course and enrollment settings follow the agreed design. The check that closes this step is a configuration baseline that matches the approved architecture, with the database and server versions confirmed against the platform's published requirements.
Integrate student systems and LTI tools
DeployOpen connects the LMS to the student information system, identity and single sign-on, and each LTI tool the faculty use, and sets up the data feeds that carry enrollments and grades. Each connection is tested with test accounts and sample courses before live data flows. The output is a tested integration register showing each connection, its data fields, its owner and the logs that record each transfer.
Test accessibility, load and recovery
Testing covers WCAG 2.1 AA conformance of the theme and the plugins, the content templates faculty will use, and load testing sized to the peak exam periods the institution has identified. Backup and restore are rehearsed on a copy of the environment. Findings are logged with severity, owner and fix date, and the institution signs off on any accepted risk. The check is a test report that shows which items passed, which were fixed and which remain open.
Document, train and hand over
DeployOpen delivers runbooks for administrators, configuration records, integration diagrams, the access and disclosure logging procedure, and the upgrade plan. Staff who will run the platform are trained on these documents and on the support path for learners and faculty. The handover is complete when the institution's named owner accepts the documents and the platform has a tested recovery procedure.
Prepare evidence and agree ongoing support
DeployOpen assembles the configuration, access, testing and logging evidence that an institution's auditors or compliance assessors may request, such as records of role assignments and the test results behind accessibility claims. DeployOpen does not issue audit reports or certifications; independent auditors and certification bodies do that work. Ongoing upgrades, monitoring, security testing and support are offered as retainers, which the institution can scope in the same written process. DeployOpen is a Chainscore Labs company.

Open source LMS for education