What a Moodle implementation involves
Moodle LMS is a PHP learning management system released under the GNU General Public License version 3 or later. It provides courses, activities, gradebooks, completion tracking, roles and a plugin system. Most of the work in a customized implementation is decisions: how departments or client groups map to categories, how learners are enrolled, which plugins are allowed and what needs custom code.
Discovery covers the courses in scope, who builds and teaches them, the systems that feed enrolments, reporting, accessibility obligations and content to migrate. It produces a site structure, an integration list, an approved plugin list and a migration plan.
Moodle Workplace, which adds multi-tenancy, programs, certifications and dynamic rules, is a commercial product offered only through Moodle Certified Partners and Service Providers. This page covers Moodle LMS, the open source edition.
Design the site structure before building courses
Changing these after courses go live means moving content and enrolments, so agree on them early.
| Building block | What to decide | Check before launch |
|---|---|---|
| Course categories | How departments or client groups nest, and who manages each category through category-level roles. | A category manager can edit courses in their own category and cannot see the others. |
| Courses and formats | Naming rules, the course format (topics, weekly or a plugin format) and a template for new courses. | A course created from the template has the agreed sections, blocks and completion settings. |
| Cohorts and groups | Cohorts for programs, intakes or departments, fed by a source system, and groups for sections or tutors inside a course. | A learner added to a cohort upstream is enrolled after the next sync, and teachers see only their group. |
| Enrolment methods | Which methods are allowed: manual, cohort sync, self enrolment, meta link, external database, LTI or payment. | Each course template has only the approved methods enabled. |
| Roles and capabilities | Whether standard roles fit or need adjusted copies, and where permission overrides are allowed. | A test account for each role can do exactly what its definition allows. |
Configuration, plugins and custom code
Site administration covers course defaults, completion, custom profile and course fields, competencies, the custom report builder and Boost theme colors and SCSS. Configuration carries no code to maintain, so use it before writing a plugin, and record every non-default setting.
The Moodle plugins directory offers activities, blocks, course formats, question types, authentication and enrolment plugins, reports and themes. Check each for support of your target version, maintenance, privacy API support and license. Every plugin needs a compatible release before you can upgrade, so keep the list short.
Build custom code as a plugin of the narrowest type that fits, such as a local plugin for integrations or a report. Use Moodle's APIs for events, tasks, privacy and web services and leave core files untouched, since core changes must be reapplied on every upgrade. Budget for API deprecations; Moodle 5.3 deprecates the old external_* classes.
Build a child theme of Boost. Moodle 5.3 removed the Classic theme from core, so Classic-based themes must be rebuilt on Boost first. Overridden Mustache templates and renderers break most often between releases, so keep overrides few.
Integrations to plan
Each integration needs an owner on both sides and a test that runs before every upgrade.
Identity and SSO
Core includes LDAP, OAuth 2, Shibboleth and multi-factor authentication. SAML2 is usually added with a community plugin. Agree the identifier that links accounts, and keep a manual administrator login for recovery.
HR and student records
Users, cohorts and enrolments can come from CSV uploads, the external database plugins, LDAP or web services. Agree which system owns each field and what happens when someone leaves.
LTI 1.3 tools
The external tool activity connects LTI 1.3 tools such as publisher content or proctoring. Moodle can also publish its own courses and activities as LTI tools.
Video classrooms
BigBlueButton is a core activity, enabled by default on new Moodle 5.3 sites, and needs a BigBlueButton server you run or contract. Other platforms connect through LTI or plugins.
Payments
Paid enrolment runs through payment gateway plugins, with PayPal in core. Confirm tax, invoicing and refund handling in discovery.
Migration, accessibility and rollout
Courses move between Moodle sites as course backups (.mbz files). Upgrading in place to Moodle 5.3 requires Moodle 4.4 or later. Content from other platforms often arrives as IMS Common Cartridge packages, imported through course restore; some need cleanup, so pilot courses from each source. Completed terms are often archived as backups or grade exports.
Moodle's documentation states that it follows the WCAG 2.2 guidelines and links to a conformance report. Custom themes, template overrides and added plugins are outside that report, so test them with keyboard, screen reader and contrast checks, and review course content for captions and alternative text.
Test on a staging copy with anonymized data, with PHPUnit and Behat tests for custom code. Roll out with pilot courses, then train administrators, category managers and course creators.
Hosting and scaling
Moodle is a PHP application with a database, a data directory and scheduled background work.
| Component | Design decision | Check |
|---|---|---|
| Web root | Since Moodle 5.1 only the public folder is web accessible. The router needs FallbackResource /r.php on Apache or try_files on nginx. | Files outside public cannot be requested, and routed pages load. |
| PHP and database | Moodle 5.3 needs 64-bit PHP 8.3 or 8.4 with PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. | The environment check passes and a point-in-time restore has been tested. |
| Data directory | moodledata must be shared storage across web nodes, while localcachedir stays on local disk. | A file uploaded through one node downloads through every node. |
| Caching | With several web servers the application cache must be shared, often in Redis, and sessions need shared storage or sticky sessions. | Purging caches on one node takes effect everywhere. |
| Cron and ad hoc tasks | Run cron every minute. Add ad hoc task runners and raise the default limit of three concurrent tasks of each kind as load grows. | No failing or overdue tasks during load tests. |
Security, privacy and backups
Moodle ships minor releases with security fixes every two months. Apply them on a schedule with an emergency path for critical fixes. Require multi-factor authentication for administrators, review the security checks report and disable plugin installation from the web interface.
The privacy API lets core and plugins support data export and deletion. Administrators manage data requests, a data registry with retention periods and site policies users must accept. Confirm each added plugin implements the privacy API.
A full backup is the database, moodledata, config.php and the deployed code with plugins, taken together. Course backups do not replace it. Rehearse a restore and check logins, files and gradebooks.
Versions, upgrades and common questions
Which version should a new implementation target?
Moodle 5.3, released on 5 October 2026, is the current LTS release, with security support until 1 October 2029. Moodle 4.5 LTS receives security fixes until 4 October 2027.
How often does Moodle release?
Major releases arrive every six months, in April and October, and minor releases every two months. LTS releases get about 36 months of security support, so teams that upgrade every two years usually stay on LTS.
What changes from Moodle 4.x to 5.x?
The public web root from 5.1, router configuration, higher PHP and database minimums, the end of Oracle support in 5.0 and the removal of the Classic theme in 5.3. Third-party plugins go inside the new public structure.
What does the GPL mean for our custom plugins?
Moodle core is GPLv3 or later. Source obligations apply when software is distributed, so plugins used only on your own site need not be published. Ask counsel about any distribution case.
Can one site serve several organizations?
Moodle LMS has no built-in tenant model. Categories, cohorts, category roles and category themes provide separation, or use separate sites when data must be isolated.
Moodle operating ownership
After launch, Moodle needs owners for the platform, the site structure, the integrations and personal data.
Platform team
- Applies minor releases on schedule.
- Monitors cron, task queues, database and storage.
- Runs backups and restore tests.
Learning technology
- Manages categories, templates, roles and enrolment.
- Reviews plugin requests.
- Trains category managers and teachers.
Integration owners
- Maintain identity, HR and LTI connections.
- Track changes on connected systems.
- Retest integrations before each upgrade.
Security and privacy
- Review administrator accounts and MFA.
- Handle data requests and retention.
- Assess new plugins before approval.
Scope and handover
Effort depends on the categories and templates, integrations, custom plugin and theme work, the volume and source of migrated courses, accessibility requirements and availability targets.
DeployOpen runs discovery, designs the site structure, deploys Moodle in your infrastructure, builds custom plugins and themes, connects SSO, HR and LTI integrations, migrates courses and trains administrators. For regulated organizations it can add security testing and compliance readiness work. Handover includes the structure document, plugin inventory, configuration record, integration runbooks, restore test results and an upgrade plan.
