Moodle for universities and colleges

At a university, the student information system is usually the source of truth for enrollments, so Moodle should receive enrollments from it and leave creating them to the SIS. That decision shapes the rest of the design. If students can self-register or instructors can add learners by hand, Moodle becomes a second record of who belongs in a course, and the two records will drift apart during a term. Before configuring anything, ask the registrar and the SIS team who owns each record type: students, instructors, course sections, term dates and enrollment status. Write the answers down. Each one becomes a rule the Moodle configuration must follow, and each gap becomes a manual task someone has to run every week.

The first technical choice is which enrollment method grants course access. Moodle's enrollment plugins differ in how they decide membership, so confirm which ones your Moodle version supports and which ones your SIS can feed. A cohort-based approach suits large intakes where a whole program moves together. Section-level enrollment suits courses where instructors need exact rosters and where a student may take different courses under different terms. Many institutions combine the two, using cohorts for program-wide content and section enrollments for individual classes. Test the combination with a sample term before committing, because changing the enrollment method later means remapping existing courses, groups and grades.

Drops and withdrawals need explicit rules. The default behavior of removing a learner can cut off access to submissions, grades and feedback that the institution may need to keep. Decide whether a dropped student is suspended or unenrolled, how long their access to the course continues, and whether the enrollment end date is set by the SIS or by Moodle. Confirm with the registrar which records must stay available after a withdrawal and for how long. Because FERPA requires institutions to record disclosures of personally identifiable information from education records, ask your compliance team to review the list of fields the sync sends to Moodle and to confirm how the feed fits the institution's disclosure records.

Identifiers tie the feed together. Map each SIS section code to one Moodle course, and decide how term codes appear in category names or course short names so that courses can be found and archived by term. Cross-listed sections and courses that merge into one roster need an explicit rule, or a student may be enrolled twice or lose access. Then decide where the connection sits. Moodle core authentication includes external database and web services options, but the exact sync mechanism depends on the institution's SIS. Confirm the supported connectors and the data each one exposes with the SIS vendor in writing, and agree who operates the service account and the network path between Moodle and the SIS.

Capacity planning for a university Moodle site starts from its peak weeks, not from average daily use. Assessment deadlines, timed exam windows and enrolment periods concentrate logins, quiz attempts, grade views and file uploads into short intervals, often on the same afternoon for thousands of students. A site that looks comfortable at 40 percent average utilization can fail in the first ten minutes of a timed quiz. Plan around the busiest hour of the busiest assessment week, and ask the institution to name those windows from the academic calendar before any hardware is specified.

Size the web and database tiers for peak concurrency, which is the number of users actively submitting or navigating at once, not total enrolled users. Quiz timing and session behavior matter here: many students start a timed quiz within the same few minutes, each attempt writes state to the database, and session locks can serialize requests from a single user. Review the session storage choice, PHP worker counts, database connection limits and any reverse proxy or load balancer timeouts. Cron and background tasks also need their own capacity. Scheduled tasks, course backups, grade syncs from the student information system and report generation can compete with interactive traffic, so run them on dedicated cron capacity and keep long jobs out of exam windows.

Backups need a window that does not collide with exams. A full backup of the database and moodledata can be heavy enough to slow quizzes, so schedule it for a period the academic calendar leaves quiet, and confirm that restore time, not only backup time, fits the recovery objective agreed with the institution. Disable or defer large course backups and bulk imports during assessment periods, and document who can override that rule.

Confirm the database engine and version first, because the supported Moodle release sets the floor. Moodle 5.1 requires 64-bit PHP 8.2 or later (8.3 and 8.4 are supported), and supports PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Moodle 5.3 raises the floor to PHP 8.3 or later (8.4 supported), PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Moodle 5.1 also changes the web server document root: it must point to the new /public directory rather than the main Moodle folder, or the site may show directory listings or errors. Update the web server configuration in the same change as the code, and test it in staging.

Sizing figures must come from the institution's own load test, run against a production-like copy of the site with realistic course content, quiz sizes and a concurrency profile taken from previous exam periods. Vendor minimums and generic benchmarks are starting points only. Agree the test scenarios, pass criteria and sign-off owner before the first high-stakes term, and repeat the test after major plugin changes or Moodle upgrades.

The split between internal staff and a partner depends on one question: who makes the decision, and who holds the data it affects. In most universities, academic and policy decisions stay inside the institution. Faculty own course design, including how courses are structured, which activities students complete and how assessments are weighted. The registrar and policy owners decide retention periods for course and user data, who can access archived courses, and what happens to enrolments when a student leaves. The student information system remains the source of record for identity and enrolment, so SIS data ownership stays with the registrar's office even when a partner builds the sync. Faculty training is also internal, because it depends on local teaching practice that no outside team can replace. Before engaging a partner, write this list down and name one owner for each item.

Fixed-scope work is where a partner usually adds the most value, because it has a defined start, deliverables and an acceptance test. Typical items include building the Moodle environment on infrastructure the institution controls, configuring SAML 2.0 single sign-on through the SAML2 Single sign on plugin (auth_saml2) or LDAP through the core LDAP authentication plugin, and building the enrolment sync from the SIS. Load testing before exam periods, upgrade planning and execution, and documentation with control evidence also fit a scoped statement of work well. Write acceptance criteria in advance. Examples include a test login from each identity provider, a sync report showing matched and unmatched records, and a load profile that reflects peak exam-week traffic as agreed with the CIO's team.

FERPA shapes this split more than any other constraint. The regulations in 34 CFR Part 99 allow an outside contractor or consultant to receive education records as a school official only if it performs a service the institution would otherwise use employees for, is under the institution's direct control for the use and maintenance of the records, and follows the redisclosure limits in 99.33(a). For a Moodle engagement, the contract should state who directs the work, which records the partner may touch, how access is granted and revoked, and what the partner may do with data after the project ends. The institution should be able to show that the partner works on its instructions and within its approval process. Confirm the exact obligations with university counsel or the privacy office before signing, since they depend on the institution's own circumstances.

The access model follows from the same rule. Under 34 CFR 99.31(a)(1)(ii), an institution must use reasonable methods, such as physical or technological access controls, so that school officials see only the education records in which they have a legitimate educational interest. For Moodle, this usually means separate build and test environments, minimized or synthetic data outside production, named accounts for each engineer, and production administrator access granted for a defined change window and logged. Decide who approves each access request, who reviews the logs and who revokes access on the day an engagement ends. FERPA also requires the institution to record each request for and disclosure of personally identifiable information from education records, along with the parties and their legitimate interests, for as long as the records are kept (34 CFR 99.32). The partner's access log should feed that record.

When comparing in-house and outside help, ask each bidder to map every task to one of three owners: the institution, the partner, or both, with a named handoff. Ask for a written scope that lists deliverables, acceptance tests and the access each role needs, and ask how access and configuration changes will be recorded during the engagement. Separate one-time costs, such as the initial build, SSO and sync configuration and load testing, from recurring costs, such as upgrades, security patching and support. Upgrades recur on the Moodle release cycle, and the starting version matters: Moodle 5.1 requires sites to be on 4.2.3 or later, and Moodle 5.3 requires sites to run 4.4 or later. Ask for a quote that follows from that written scope.