Why a self-hosted course platform for universities differs from other sectors
A university rarely runs one kind of course platform. It runs open MOOCs for public audiences, paid continuing programs, and credit-bearing courses that touch enrollment, grades and transcripts. Those courses share infrastructure but not rules. Student records are the constraint that changes the build. Under FERPA (34 CFR Part 99), an institution that gives a platform vendor or implementation partner access to education records must keep that party under its direct control, limit its use of the data, and restrict staff access to the records they have a legitimate educational interest in. GLBA's Safeguards Rule applies to Title IV institutions through their Program Participation Agreements, which requires a written information security program and multi-factor authentication for anyone accessing an information system. If the platform admits learners under 13, the COPPA Rule (16 CFR Part 312) adds a written security program, a designated coordinator and a retention policy with a deletion timeframe.
The short answer is to match the platform to the audience and the integrations. Open edX suits open course catalogs with large anonymous or semi-public audiences, public-facing course pages and xAPI-based learner analytics. Moodle suits credit-bearing and institution-wide teaching, where course enrollment must link to the student information system, gradebook rules and faculty roles already used across the campus. Many universities run both, which means deciding early which system is the system of record for enrollment and completion. Confirm with your registrar and privacy office which data each platform will hold, how long it will be kept, and who can see it before any learner account is created.
Before procurement, ask your implementation partner for a written data map covering each integration point, a list of the roles that can open learner records, and a plan for the deletion of under-13 data. Confirm whether your institution's FERPA and GLBA obligations are handled by your compliance office or by the partner, and whether the partner will sign the agreements your counsel requires for a school official arrangement. These decisions shape hosting location, identity federation and log retention, so they should be settled before the first course is built.
Which university rules change the course platform build
This table maps the US federal rules that most often shape a university course platform to the build decisions they force, from learner record access to accessibility dates. Read each row as a question to answer in the architecture, the data model and the operating runbook before the platform goes live. Rules that apply depend on your institution's funding, student population and legal counsel's reading, so confirm applicability first.
| Rule | What it requires | What it means for the build |
|---|---|---|
| FERPA school official and access control (34 CFR 99.31) | Outside contractors may see education records as school officials only for a service staff would otherwise perform, under direct institutional control, and access must be limited by reasonable physical or technological controls. | Use role-based access so instructors, advisors, vendors and integration accounts see only the learner records their role needs. Put the implementation partner under a written agreement that sets direct control over records. |
| FERPA disclosure record (34 CFR 99.32) | Institutions must record each request for and disclosure of personally identifiable information from education records, with the parties and their legitimate interests, for as long as the records are kept. | Build an audit log of disclosures and access to learner data, including API pulls to the student information system and exports to third parties. Confirm with counsel how long logs must be retained and where they are stored. |
| FERPA inspection window (34 CFR 99.10) | Institutions must respond to a parent's or eligible student's request to inspect records within a reasonable period and no more than 45 days after receiving it. | Make learner records findable by student identifier across the LMS, the certificate store and the analytics layer. Test that a full record export can be produced within the 45-day limit, not only in a demo. |
| GLBA Safeguards Rule for Title IV institutions (16 CFR Part 314) | Title IV institutions must maintain a written information security program, require multi-factor authentication for anyone accessing any information system, and notify the FTC within 30 days of a notification event affecting at least 500 consumers. | Enforce MFA for staff, administrators and vendor support accounts on the course platform, the database host and the hosting console. Document the written program and an incident path that meets the 30-day FTC notice. |
| COPPA for learners under 13 (16 CFR Part 312) | Operators collecting personal information from children under 13 need a written security program with a designated coordinator, at least annual risk assessments and a written retention policy with deletion timeframes. | Separate or flag accounts for minors, limit collected fields, and set automated deletion for learner data that is no longer needed. Assign a named coordinator and schedule the annual risk assessment in the operating plan. |
| ADA Title II web accessibility (28 CFR Part 35 Subpart H) | Public universities must meet WCAG 2.1 Level AA for web content and mobile apps, 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. | Confirm which population band your institution falls into. Test course players, quizzes, certificates, the theme and any custom plugins against WCAG 2.1 AA before those dates, and budget remediation for third-party content and video captions. |
Open edX or Moodle: which platform fits which university program
Open edX is built for open online courses that a university publishes to anyone who registers, with a Studio authoring environment for course teams and an LMS for learners. The platform is licensed under AGPL-3.0, which matters if you plan to modify the code and offer it as a network service. Open edX supports only the latest named release at any time. Verawood is the current named release, published on 30 July 2026, and Willow is planned for December 2026. A university running a public catalog should plan an upgrade path onto each named release rather than treating the first deployment as a fixed state.
- Release discipline: Plan for a release cycle that moves the site onto each named release, because only the latest named release is supported.
- Course authoring: Studio and the LMS suit multi-course catalogs where course teams author content on a shared platform.
- Authentication: Third-party authentication covers OAuth2 providers, SAML 2.0, Shibboleth and LTI, so confirm which one your identity team will expose.
- Operations: Production deployments are usually run through a service provider or with Tutor, since the maintainers note that bare-metal installation is complex.
- Analytics: Aspects captures xAPI-based tracking logs, which the analytics team should review before launch.
Confirm with course owners and the identity team which identity provider learners will use, and whether the catalog will need an upgrade plan before the next named release.
Credit-bearing and institution-wide courses tend to fit Moodle better because the platform is already widely used for graded coursework, cohort management and integration with campus systems. Moodle is licensed under GPL-3.0 and maintained by Moodle HQ. Moodle 5.3 is the current long-term support release, with bug fixes until 4 October 2027 and security fixes until 1 October 2029. Moodle core includes authentication plugins for manual accounts, LDAP, LTI, OAuth 2 and Shibboleth, which can reduce the number of add-ons needed to connect to student identity.
- Long-term support: Moodle 5.3 has security support until 1 October 2029, which gives registrars and IT a longer planning window than a rolling release.
- Built-in authentication: LDAP, Shibboleth and OAuth 2 ship in core, so confirm whether your directory needs the SAML2 plugin instead.
- Upgrade requirements: Moodle 5.3 requires PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later, and sites must run Moodle 4.4 or later to upgrade.
- Web root change: From Moodle 5.1, the web server document root must point to the /public directory.
- Academic features: Moodle 5.3 adds a learning outcomes feature, which course owners and accreditation staff should assess against program requirements.
Confirm with the registrar and course owners which grading, enrollment and transcript workflows the platform must support before selecting a version.
Many universities run open catalogs and credit programs side by side, and the platform choice then becomes an architecture question. One option is to run Open edX for public courses and Moodle for credit programs, linked through shared identity and a clear data boundary. A second option is to standardize on one platform and accept its trade-offs for each program type. Canvas LMS, licensed under AGPL-3.0, is also worth evaluating as an alternative, especially where the institution already uses it for campus learning. Each option carries separate upgrade calendars, hosting footprints and support contracts.
- Two platforms: Separate platforms give each program its own release cycle, but double the hosting, identity connections and support work.
- One platform: A single platform reduces operational overhead, but may fit one program type less well than the other.
- Shared identity: Whichever model you choose, a single identity provider and consistent learner IDs simplify reporting across programs.
- Canvas evaluation: Canvas LMS is AGPL-3.0 licensed and should be tested against the same requirements before it is ruled in or out.
- Data boundaries: Decide early which learner records move between platforms and which stay in the student information system.
Before committing, ask the registrar, identity team and course owners to confirm which program types and reporting needs drive the decision, and document the upgrade calendar for each platform.
How a university rollout moves from data review to cohort launch
The sequence turns a university's course goals into a platform that handles learner records lawfully, signs students in through the campus identity provider, carries each program's branding, and holds up under launch-day traffic. Each phase closes with a written output that the next phase depends on.
Classify data and scope FERPA with the registrar
The registrar, general counsel and the DeployOpen team list every data element the platform will hold, including names, enrollment status, grades, certificate records and learner activity logs, and mark which ones are education records under FERPA. The group decides which vendor roles qualify as school officials, documents the legitimate educational interest for each role, and sets access controls so staff see only the records they need. Where the course offering includes learners under 13, the team also checks the COPPA obligations for those learners. The output is a signed data classification register and a FERPA scoping memo that the platform design must follow.
Design identity and student system links
The team maps how learners and staff sign in, choosing between SAML 2.0 or Shibboleth federation with the campus identity provider, and decides which accounts remain local, such as external or open-enrollment learners. It then defines the LTI connections to the student information system or the institution's existing LMS, including which roster, grade and enrollment data flows in each direction. Because the identity design determines who can see which records, the registrar and security team review it before any build work begins. The output is an identity and integration design document listing each trust relationship, attribute mapping and data flow, with the owner of each one named.
Build the platform with Tutor or Moodle
The engineering team deploys the chosen platform in the university's own cloud account, data center or private network. For Open edX, this usually means Tutor in its Docker-based or Kubernetes form, while Moodle is installed on a web server, database and cache stack that matches the version's supported PHP and database requirements. The team configures the identity connections from the previous phase, sets up backups and secrets handling, and documents each configuration decision in the runbook. The output is a non-production environment that passes sign-in, roster sync and grade passback tests with a sample set of test accounts.
Apply branding for each program
Designers and the program owners agree on a theme for each program, covering logos, color, course landing pages, certificate templates and email sender details. The team implements these as theme and configuration changes that the upgrade process can carry forward, rather than as edits to core files. Each program's branding is tested on the sign-in page, course catalog and certificate output, and the team confirms that the institution's brand standards are met. The output is a branded staging site per program, with a sign-off record from each program owner and a list of any customizations that will need retesting at upgrade time.
Test accessibility against WCAG 2.1 AA
The team runs automated checks and manual testing with assistive technology against the learner-facing pages, course content templates, forms and certificate pages, mapping findings to WCAG 2.1 Level AA success criteria. Public universities should confirm with counsel how the ADA Title II web rule and its compliance dates apply to their entity, since the rule sets a specific standard for state and local government web content. Failures are logged with severity, owner and fix date, and retested before sign-off. The output is an accessibility test report and a remediation log that show which criteria passed, which were fixed, and which remain open with an agreed plan.
Load test before the cohort launch
The team models expected concurrent sessions, enrollment spikes and video playback for the launch, then runs load tests against a copy of production that matches its database, cache and content delivery setup. Results show where sessions slow down or fail, and the team tunes database connections, cache sizing and the video delivery path before the launch date is set. The launch-day plan includes a monitoring dashboard, an on-call roster and a rollback path. The output is a load test report with the tested scenarios, the bottlenecks found and fixed, and a go or no-go checklist signed by the institution.
Hand over with a supported upgrade path
The team transfers operational documentation, access records, backup and restore procedures, and the monitoring setup to the university's operations staff, and walks them through a restore test. It confirms the release line the platform runs and the support window for that line, since Open edX supports only the latest named release and Moodle publishes separate general and security support dates for each version. The handover includes a written upgrade plan that names the owner of each upgrade, the test environment used and the retesting of customizations. The output is a signed handover package and a confirmed support arrangement, whether internal, with DeployOpen under a retainer, or with another provider.
Questions universities ask before hiring an implementation partner
What drives the cost of a university course platform implementation?
The cost follows the scope agreed in writing, and five drivers move it most: identity integration with the university's login, credit and certificate rules, payment setup, the number of programs and their branding, and accessibility remediation of existing course content. Identity work grows with each protocol and each identity source (for example, a SAML 2.0 federation with the campus directory versus a single social login). Credit and certificate rules grow with each program type that needs its own logic. Payment setup depends on whether the university charges learners, which gateways it already holds, and how invoices and tax are handled. Accessibility remediation depends on how much legacy content must be reworked. Ask for a quote that lists each driver as a separate line item with its assumptions, and separate one-time build work from recurring hosting, support and upgrade work.
How long does a university course platform rollout take?
The timeline depends on scope, not on the platform choice alone. A pilot with one program, existing login and no paid enrollment is far shorter than a multi-program launch with campus single sign-on, payments, certificates and integration with the student information system. Open edX releases also set a planning constraint: the latest named release is the only supported one, and the next releases are listed for December 2026 (Willow) and June 2027 (Xylon), so a launch window may need to account for which release is current when work starts. Ask the partner to show the phases, the dependencies on the university's own teams and the acceptance tests for each phase, and to state which items are fixed in the written scope.
What must the university's IT, registrar and course teams provide?
Each team owns inputs that the implementation cannot invent. IT must supply identity sources, metadata for federation, network rules, DNS, certificates, hosting accounts and a named security contact. The registrar must define credit rules, grading scales, transcript and certificate wording, and which records are official. Course teams must provide content, accessibility status of existing material, instructor accounts and sign-off on learner-facing terms. Delays usually come from missing decisions rather than from technical work, so ask the partner for a written input list with an owner and a due point for each item before the schedule is accepted.
Can our staff run the platform themselves after handover?
Yes, if the university staffs the roles the platform needs, and the handover plan defines them before launch. Running Open edX in production typically calls for operators who can manage the deployment, databases, caches and upgrades. The edx-platform maintainers recommend a service provider or Tutor for production, and note that bare-metal installation is complex and receives limited community support. Moodle has its own operational needs, including PHP, database and web server configuration. Ask for runbooks, documented configuration, backup and restore tests, and a clear split between what the university operates and what a retainer covers. Confirm the skills needed with your own engineers before agreeing to self-operation.
Does a MOOC-scale launch need a separate hosting design?
Yes, when expected enrollment and concurrent learners are far above a single program's needs. Scale changes the architecture: the platform needs a shared cache backend across several nodes, sized databases, video delivered through a content delivery network rather than the application server, and load testing before each large launch. Open edX deployments on Kubernetes with Tutor are one option, and Moodle uses its own clustering approach, so the choice should be made against the expected peak, not the average. Ask the partner for the peak assumptions behind the design, the load test plan and the operating team needed during launch windows.
Which compliance duties change the scope of the build?
Student records, identity data and payment handling each bring their own duties, and they should be scoped at the start. FERPA applies to institutions that receive funds from programs administered by the US Secretary of Education, and it governs how education records are shared with contractors and how access is logged. A partner acting as a school official must operate under the institution's direct control and follow redisclosure limits. The GLBA Safeguards Rule applies to Title IV institutions and requires a written information security program and multi-factor authentication for system access. Accessibility duties under the ADA Title II rule apply to public universities, and the interim final rule set compliance dates of April 26, 2027 and April 26, 2028 depending on entity size. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the findings. Confirm the applicable rules with your counsel and compliance office.
What does the partner need to answer about identity and student data access?
The partner should explain which login protocols the platform will use, who holds the identity source, and how access to learner records is limited to staff with a legitimate educational interest. Open edX supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, while Moodle core includes LDAP, OAuth 2, Shibboleth and web services plugins. Ask how role mapping works for instructors, registrars and administrators, how access logs are kept, and how the team tests account deprovisioning. Confirm each supported protocol against the university's own identity provider before committing to a design.
What to ask a partner about FERPA, identity and upgrades
Start with FERPA, because the partner's role determines what they may touch. Ask how the partner qualifies as a school official under 34 CFR 99.31(a)(1)(i)(B): which services it performs that the university would otherwise staff internally, how the university keeps direct control over the use and maintenance of education records, and how the redisclosure limits in 99.33(a) are written into the contract. Then ask for the technical access controls that restrict each engineer and support role to the records they need, as 99.31(a)(1)(ii) requires. Ask for the disclosure log design too. Under 34 CFR 99.32, every request and disclosure of personally identifiable information must be recorded with the parties and their legitimate interests for as long as the records are kept, so the partner should show where that log lives in an Open edX or Moodle deployment and who can read it.
Next, test identity before go-live rather than trusting the setup. For Open edX, ask which third-party authentication path the campus identity provider uses (SAML 2.0, Shibboleth, LTI or OAuth2) and how the partner confirms attribute mapping, account linking and deprovisioning for a departed student. For Moodle, ask whether the site uses the core SAML or LDAP options or a plugin such as the SAML2 Single sign on plugin, and who maintains that plugin after upgrades. Ask for a written test plan covering login, logout, role assignment from campus groups and a failed-login path, and confirm that multi-factor authentication for staff accounts follows the institution's own policy, since the Safeguards Rule in 16 CFR Part 314 applies to institutions in the Title IV programs.
Upgrades and accessibility are the last two checks. Open edX supports only the latest named release, and the next named releases are planned for December 2026 (Willow) and June 2027 (Xylon), so ask how the partner schedules each move and tests course content against it. For Moodle, ask which LTS line the university will hold, how security support dates shape the upgrade calendar, and how the partner handles the Moodle 5.1 change that moves the web root to /public. On accessibility, ask for the WCAG 2.1 Level AA test method, the audit tools and the evidence of remediation, and check the compliance date that applies to the university's population under the ADA Title II rule. Finally, ask who operates the platform after launch, who holds on-call duties, and who pays for each recurring service.
Evidence a university can show auditors and regulators
This table maps each piece of compliance evidence to the platform component that produces it, the regulation it supports and where it most often falls short. DeployOpen prepares these controls and records for review, but independent auditors and regulators make the assessment, and DeployOpen does not issue audit reports or certifications. Use it to decide which artifacts to request during scoping.
| Evidence | Produced by | Where it usually falls short |
|---|---|---|
| FERPA legitimate interest access configuration and role assignments | Open edX LMS and Studio roles, or Moodle role and capability settings, plus identity provider group mapping | Staff accounts keep roles after a change of duties, and vendor or contractor accounts are not limited to their service |
| FERPA disclosure log of access and disclosures of personally identifiable information | Audit logging in the LMS, reporting database and any integrations that export learner records | Logs exist but do not record the requesting party and legitimate interest, or are not retained for as long as records are kept |
| Contractor school official agreement and direct control evidence | Written agreement with the implementation partner, administrator access register and change records | Partner access is granted informally, and no record shows the institution controls use and maintenance of the records |
| GLBA multi-factor authentication configuration | Identity provider policies enforced at the LMS login, admin consoles and hosting control planes | MFA covers the learner portal but not server shells, database consoles, backup systems or payment administration |
| Written information security program documents | Risk assessment, asset inventory, incident response plan and designated coordinator records maintained by the university | Documents are written once and not updated after platform upgrades, new integrations or staff changes |
| WCAG 2.1 Level AA accessibility test reports | Automated scans plus manual testing of course player, theme and custom pages, with remediation tickets | Testing covers the default theme only, and course content uploaded by faculty is never checked |
| Backup and restore test records | Backup job logs, restore drill reports and retention settings for database, media and course content stores | Backups run successfully but no restore has been tested, so recovery time and completeness are unknown |
| Upgrade and patch records | Change tickets, release notes reviewed, test results and deployment logs for each named release or LTS update | Platform runs a release that is no longer supported, or security fixes lag behind the published support window |
Integration points between the course platform and student systems
A university course platform is only as useful as its connections to the rest of campus. Each integration below has a protocol or plugin choice, a data owner and a point where a mistake exposes student records, so settle them in the design phase rather than after launch.
Campus identity provider
Students and faculty should sign in with the university account, not a second password. Open edX supports SAML 2.0, Shibboleth and OAuth 2 providers through third-party authentication, and Moodle core includes OAuth 2, Shibboleth and LDAP plugins, with SAML 2.0 available through the auth_saml2 plugin. Confirm which attributes the identity provider releases (eduPersonAffiliation-style roles, program codes), how deprovisioning works when a student leaves, and who owns the metadata exchange. Confirm the attribute release policy before the first pilot cohort.
Student information system and enrollment feeds
The student information system (SIS) is usually the source of truth for who is enrolled in which program. Decide whether enrollments flow in by scheduled file, API or LTI launch, and whether the course platform ever writes grades or completion back to the SIS. Moodle core includes an external database authentication plugin and web services, which can support feeds, but the mapping of course IDs to program codes is custom work. Confirm the SIS vendor's API limits, the feed frequency and who reconciles rejected records.
Payment and billing for paid programs
Paid programs need a payment path that ties a completed purchase to an enrollment, plus invoices that match the university finance system. Moodle supports enrolment on payment through gateway plugins, and Open edX commerce integrations vary by release, so confirm which gateway and tax setup your finance office accepts before choosing the platform. Card data handling changes PCI DSS scope, so favor hosted payment pages over card data passing through your servers. Ask who reconciles refunds and who answers a learner's failed payment.
Analytics and retention settings
Learning analytics feed course quality reviews and accreditation reports, but they also create a large store of personal data. Open edX Aspects captures tracking logs as xAPI statements, stores them in ClickHouse through Ralph or Vector and presents them in Superset. Moodle exposes its own logs and reports, and log retention is a site setting you must configure. Confirm the retention period for raw events, who can query identifiable data and how a deletion request is carried out across the analytics store.
Video hosting
Lecture video is the heaviest traffic on the platform and the most common source of cost surprises. Decide between self-hosted video storage behind a content delivery network, an institutional video service that the platform embeds, or a third-party host. Each option changes who holds learner viewing data and which accessibility captions workflow applies. Confirm the caption format the platform accepts, whether signed or private links are supported for paid content, and how video is licensed for MOOC reuse.
Public marketing site
The catalog, program pages and enrollment calls to action usually live on a separate public site that the registrar or marketing office already runs. Connect the two with consistent course identifiers, shared branding and single sign-on handoff rather than duplicating catalog data by hand. Confirm which system is the master for course descriptions, prices and dates, how catalog changes publish to the learning platform, and whether the public site must meet the accessibility standard the university has adopted for public web content.
How DeployOpen scopes and supports a university course platform
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted Open edX or Moodle inside the university's own infrastructure, whether that is its cloud accounts, a data center or an isolated network. The work is agreed as a fixed-scope written agreement before anything is built. For a university, that document should name the platform and its distribution method, the identity providers and student information system connections in scope, the number of course programs and branded sites, the environments (development, staging and production), the handover items and the acceptance tests. Ask every partner to write out what is excluded, especially payment gateways, video hosting, and any student records work that depends on the registrar's own systems.
Security testing and compliance readiness are separate line items from the build, and they should be scoped as such. Application and API testing covers the Studio and LMS interfaces, the LTI and single sign-on endpoints and any plugin or theme code the university adds. Infrastructure testing covers the database, cache and storage tiers. Compliance readiness means preparing configuration baselines, access reviews, retention settings and evidence for the controls that FERPA, the GLBA Safeguards Rule or other frameworks your counsel identifies will examine. DeployOpen prepares systems and evidence for those assessments but does not issue audit reports, attestations or certifications. Your independent assessor or certification body does that work, so confirm early which evidence they will request and in what format.
Upgrades and day-two operations are usually the cost that surprises universities most. Named Open edX releases are supported only while they are the latest release, and Moodle security support windows differ by version, so plan a retainer that covers upgrade testing, plugin compatibility checks and security patching on a schedule your academic calendar can absorb. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which the university can ask to be priced separately from the initial build. Before signing, ask the partner who holds on-call duty, how backups are restored and tested, what the escalation path is during a cohort launch, and how the platform is documented so that your own team can take it over if the relationship ends.
