What upgrades and support involve for Moodle
A self-hosted Moodle site never stops needing attention. Moodle HQ ships major releases every six months, in April and October, and point releases every two months in February, April, June, August, October and December. Each major release sets its own minimum PHP version, supported database versions and upgrade-entry requirement, so an upgrade is rarely just a code swap. Before planning any move, confirm the current release calendar and the support end dates on the Moodle releases page, then map your site's current version against them.
Four events usually start an upgrade. The first is a support end date getting close, which ends general or security fixes for your version. The second is a security release, which often must be applied quickly and cannot wait for a planned window. The third is a PHP or database version reaching end of life on your hosts, which forces a platform change even when Moodle itself is current. The fourth is a new plugin or feature need that only exists in a newer release. Note which trigger applies to each upgrade, because it sets the deadline and how much testing you can afford.
Who does this work? Teams with an experienced administrator, a test environment that mirrors production, and a clear owner for plugin compatibility often keep upgrades in-house. Teams without that capacity usually bring in a partner for the major upgrades and keep routine point releases internal. A split is common: the internal team applies point releases and monitors support dates, while a partner handles major version jumps, plugin re-validation and post-upgrade fixes. Decide this before go-live, and write the split into your support agreement.
What the service includes
Each package produces a named deliverable you keep, so an upgrade can be reviewed, repeated and audited without relying on any one person. Scope is agreed in writing before work starts.
Release and support-window tracking
We track each Moodle release against its support window, separating general support from security-only support so you know when a version stops receiving fixes. Moodle ships majors in April and October and point releases in February, April, June, August, October and December. The deliverable is a maintenance calendar with target versions, decision dates and the security-only end dates for your installed branch.
Environment and runtime checks
Before any code changes, we check the PHP version, database engine and version, web server configuration and the document root against the target release requirements. From Moodle 5.1 the web server must point at the /public directory, or the site may show directory listings or errors. The deliverable is a readiness report listing each gap, its owner and the change needed.
Plugin and theme compatibility review
Every installed plugin and theme is matched against the target Moodle version, checking its declared support, maintenance status and any removed core features it depends on. Unmaintained or abandoned plugins are flagged with a replace, retain or remove recommendation. The deliverable is a compatibility matrix that records the decision for each component.
Staging upgrade with regression testing
We rebuild a copy of production on staging, run the upgrade, and test the workflows your institution depends on, such as enrolments, gradebook, assessments, reports and SSO sign-in. Test results are logged against a written test script. The deliverable is an upgrade report covering defects found, fixes applied and any open items for your sign-off.
Production cutover with rollback
The production upgrade follows a tested runbook with a fixed sequence for maintenance mode, backups, code deployment, database upgrade, cache purge and cron checks. A verified backup of the code, moodledata and database is taken first, and the rollback path is rehearsed on staging. The deliverable is a tested runbook and a rollback procedure with the decision point defined in advance.
Post-upgrade monitoring
After cutover we watch error logs, scheduled task failures, slow queries and login behavior for an agreed period, and compare them with the pre-upgrade baseline. Issues are triaged and fixed in the order that affects learners first. The deliverable is a post-upgrade monitoring summary with the baseline comparison and a list of follow-up actions.
Ongoing security release application
Moodle publishes security releases between scheduled point releases, and these need to be applied on your timetable without drifting onto unsupported code. We test and apply security releases to your environment and record the change. The deliverable is a change log of applied releases, with the test evidence and any plugin updates that were required alongside them.
What drives upgrade and support effort
This table lists the factors that change how much work each Moodle upgrade and ongoing support cycle takes, with the reason each one matters and how to keep it under control.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Installed plugins, especially third-party and custom code | Every plugin must be checked for compatibility with the target release, and custom code needs regression testing because it is not covered by core upgrades. | Inventory every plugin with its source and version, remove unused ones, and prefer maintained contributed plugins over custom code where a supported option exists. |
| Custom themes and template overrides | Overridden templates and theme code can break when core markup or navigation changes, which Moodle 5.3 illustrates by removing the Classic theme from core. | Use a child theme, keep overrides minimal, and record every overridden template so it can be reviewed at each upgrade. |
| Distance from the current version | Sites must be on a supported entry version to upgrade, so a site behind 4.2.3 (for 5.1) or 4.4 (for 5.3) needs intermediate steps before the target upgrade. | Track the installed release against the minimum upgrade-entry version for each target, and plan upgrades on the six-monthly or LTS cadence instead of skipping releases. |
| PHP version in use | Moodle 5.1 requires 64-bit PHP 8.2 or later and Moodle 5.3 requires 64-bit PHP 8.3 or later, so a PHP upgrade may be needed before or with the Moodle upgrade. | Confirm the PHP version against the target release notes, test PHP upgrades on staging first, and check plugins for PHP compatibility. |
| Database engine and version | Floors differ by release, including PostgreSQL 15 for 5.1 and PostgreSQL 17 for 5.3, and a database upgrade can be a separate project with its own backups and rollback. | Check the database floor for each target, schedule database upgrades as their own change, and confirm vendor support for the engine you run. |
| Number of environments | Development, test, staging and production each need the same core, plugin and theme versions, and every environment adds a copy to upgrade and keep aligned. | Keep the number of environments to what the team can maintain, automate deployment of code and configuration, and refresh staging from production under documented rules. |
| Identity and external integrations | SSO plugins, HR feeds, web services and external databases each depend on the Moodle version and must be retested because they often fail silently after upgrades. | List each integration with its owner and test endpoints, keep connector versions pinned, and include login, enrolment and grade sync in every upgrade test. |
| Data volume and course content for regression checks | Large course counts, quizzes, and archived content increase the time for upgrade scripts and the number of pages a tester needs to check. | Define a representative set of courses and activities for regression testing, archive or remove stale courses, and measure upgrade duration on a production-sized copy. |
| Core customization | Changes made inside core files are overwritten or conflict with each security and minor release, making every upgrade a manual merge. | Replace core edits with plugins, theme overrides or configuration, and record any unavoidable core change so it can be reapplied and tested each time. |
How an upgrade engagement runs
The sequence moves a live Moodle site to a supported release with a tested path, a rollback option and a documented run process after go-live.
Inventory the site and assess the current version
We record the installed Moodle version, PHP and database versions, web server layout, cron setup, installed plugins and themes, custom code, and the data volumes in moodledata and the database. The output is a written assessment that states the current version, its support status, and whether a direct upgrade path exists from that version. Confirm the current release and its support window against the Moodle releases page before scoping.
Review compatibility of PHP, database, plugins and theme
We check the target release's PHP and database requirements against the server stack, then test each plugin and the theme for compatibility with the target version and with the minimum version the upgrade requires. The output is a compatibility register listing each item as compatible, needs an update, needs replacement, or needs removal, with the owner of each decision. Confirm requirements in the release notes for the exact target version.
Agree the upgrade plan and target release
We set out the target release, the intermediate steps if one is needed, and the reasons for the chosen support window, including the general and security support end dates for each candidate release. The output is a written plan covering sequence, change freeze, dependencies, rollback approach and the decisions your team must make. The plan and its timing are fixed in the written scope and depend on the factors in the effort drivers table.
Rebuild staging and rehearse the upgrade
We build a staging environment that matches production in server configuration, PHP and database versions, plugins and a recent copy of data, with personal data handled under your data protection rules. We run the full upgrade on staging, record every step and error, and repeat the rehearsal until it completes cleanly. The output is a rehearsed runbook with timings measured on your own environment.
Run regression and accessibility checks on key course flows
We test the flows that matter most to your institution, such as enrolment, course access, quizzes, assignments, gradebook, completion tracking, SSO sign-in, and any integrations, and we check key pages against accessibility criteria with a documented method. Your course owners sign off on their test cases. The output is a test report listing pass, fail and accepted-risk items, with each fix retested on staging.
Cut over to production with backup and rollback ready
We take a verified backup of the database and moodledata, place the site in maintenance mode, run the rehearsed runbook, and check the result against the agreed acceptance list. If a blocking failure appears, we follow the rollback procedure from the backup and record the decision. The output is a signed-off production release with a record of the backup, the version change and the checks performed.
Hand over through hypercare to your run team
We monitor logs, cron, performance and support tickets for the agreed hypercare period, fix defects found in use, and transfer runbooks, patching steps, plugin update procedures and escalation contacts to your administrators. The output is a handover pack and a closed hypercare log, with ongoing support available under a separate retainer if you want it.
What your team keeps and what a partner can take
This table shows, for each part of a Moodle upgrade cycle, who usually owns the work and which skills it needs, so you can see which parts a partner can run and which stay with your institution.
| Work part | Usually owned by | Skills it needs |
|---|---|---|
| Release tracking | Institution, with partner input | Reading the Moodle release calendar, support end dates for each branch, and the institution's academic term calendar |
| Environment ownership | Institution's infrastructure team | Server, PHP, database and web server administration, plus access control to production and staging |
| Plugin vetting | Partner for compatibility checks, institution for approval | Plugin code review, checking version support for the target Moodle release, and judging whether a plugin is still maintained |
| Upgrade rehearsal | Partner, with institution staff verifying results | Database and file backup and restore, Moodle CLI upgrade steps, and running the upgrade against a copy of production data |
| Production cutover | Partner runs the technical steps, institution approves timing | Maintenance mode planning, rollback steps, cron and cache handling, and post-upgrade smoke checks |
| Incident response | Institution service desk, with partner escalation | Log analysis, Moodle and PHP error diagnosis, and a shared runbook covering who is called and when |
| User communication | Institution communications and academic support teams | Writing downtime notices and release notes for students, staff and faculty in plain language |
| Course-owner acceptance testing | Course owners and academic staff, who must sign off | Subject knowledge of their courses, quizzes, grading and activities, and the ability to record defects clearly |
What usually goes wrong and how to prevent it
Most Moodle upgrade problems are predictable and come from a small set of version, configuration and process gaps. Check each item before the upgrade window opens, not during it.
Skipping below the upgrade entry version
Moodle only upgrades from a minimum supported version, so a site older than that line cannot move directly to the target release. For 5.1, the documented entry point is Moodle 4.2.3 or later. Confirm your current version and plan intermediate upgrades in writing before estimating the window.
Web server still pointing at the old root
From Moodle 5.1, the web server document root must point to the new public directory instead of the main Moodle folder. If it does not, users may see directory listings or errors after cutover. Update the virtual host, reverse proxy and any load balancer health checks in the same change window, and test them on staging first.
Third-party plugins without a target release
Contributed plugins often lag behind core releases, and a plugin with no version for the target Moodle release can block the upgrade or break a feature silently. Build an inventory of every plugin, its source and its compatibility for the target version, and decide per plugin whether to replace, upgrade or remove it.
PHP or database below the new floor
Each major release sets a minimum 64-bit PHP version and minimum database versions, and the floor rises over time. Compare your current PHP, PostgreSQL, MySQL, MariaDB or SQL Server versions against the target release notes before scheduling. Upgrading the runtime is usually a separate, earlier change that needs its own test pass.
Custom theme code broken by removed components
Custom themes and local code can depend on templates, renderers or components that a release changes or removes. The Classic theme left core in 5.3, so any site still relying on it must move to another theme. Review custom theme and local code against the release notes, and run page-by-page checks for core pages, course views and gradebook.
Upgrade run without a tested rollback
An upgrade that changes the database schema cannot be undone by simply swapping code back. Before the production run, take a database dump and a moodledata copy, restore both to a separate environment, and confirm the site starts on the previous code. Record the time that restore takes so the rollback decision is made from evidence.
Security releases applied late
Moodle publishes minor point releases on a fixed bi-monthly pattern, and security fixes are released within that cycle. Support windows also end on set dates, for example Moodle 5.1 security support ends 19 April 2027. Track the release calendar, assign an owner for each patch cycle, and set a rule for how quickly security releases go to production.
Cron and task workers left on old code
Scheduled tasks and ad hoc workers run PHP outside the web request, so they can keep executing the previous code after the web tier has moved. Mixed versions can corrupt data or fail silently. Stop workers before cutover, point every cron entry and worker service at the new installation, and confirm task logs show a clean run afterward.
How the work changes by starting point
A site already on a current release with a short plugin list usually has the smallest upgrade plan. The work centers on confirming the target version and running a clean test upgrade, not on rebuilding anything.
- Version check: confirm the current release, its support end date and the minimum PHP and database versions for the target.
- Plugin list: check each contributed plugin for a release that matches the target version before you schedule the test.
- Test copy: restore a recent database and moodledata copy into a staging environment and run the full upgrade there first.
- Evidence to expect: the staging upgrade log, a list of plugins checked, and a smoke test script covering logins, gradebook and course access.
- Support handover: a written patching calendar that tracks security and minor releases after go-live.
A site several major versions behind usually needs more than one upgrade step, and an older PHP or database version often has to change before Moodle itself can move. Each step needs its own test, and the order of steps becomes part of the plan.
- Upgrade path: Moodle only upgrades from specific earlier versions, so map the path from your current release to the target, including any intermediate release you must stop at.
- Runtime changes: confirm the PHP and database versions each step requires, and plan the server work that comes before the Moodle work.
- Old plugins: expect some contributed plugins to be unmaintained, and decide whether to replace, rebuild or drop each one.
- Evidence to expect: a step-by-step upgrade record, a runtime inventory before and after, and a list of removed or replaced features with owners.
- Rollback: a tested backup and restore for each step, with the time it takes to restore recorded.
A site with many custom plugins and themes carries the most effort per release, because each custom component must be checked against core APIs and templates that may have changed. The plan is driven by the size of the custom code, not by the core version alone.
- Inventory: list every custom plugin and theme with its type, owner, core APIs used and last review date.
- Compatibility review: check each component against the target release, including removed or renamed templates and deprecated APIs.
- Owner sign-off: each custom component needs a named owner who tests their features in staging before the cutover.
- Evidence to expect: a compatibility matrix per component, test results for custom features, and a change log tied to each release.
- Quote question: ask how custom code is tested, who fixes it after a core release, and whether that work recurs in your support retainer.
A site moving from managed hosting to self-hosting takes on server, backup, patching and security duties that the provider handled before. The upgrade plan must include the new hosting baseline, not only the Moodle version.
- Access inventory: list what the provider configured for you, such as the web server, PHP settings, cron, backups and certificates, and assign each item an owner.
- Environment match: rebuild the runtime to match the target requirements, including the document root and database version.
- Data export: confirm you can take complete backups of the database and moodledata, and test a restore on your own infrastructure.
- Evidence to expect: a responsibility matrix, a documented build, and restore test results.
- Ask the provider: confirm what data export they support and what they will not hand over, since some plugins or settings may not transfer.
A site on an air-gapped or restricted network cannot pull packages, plugins or updates from the internet at upgrade time. Every Moodle release, PHP package, database package and plugin must be imported and verified inside the network before it can be used.
- Offline repository: mirror the approved Moodle code, PHP and database packages, and plugins into an internal store with a documented process.
- Verification: record checksums or signatures for each imported artifact and keep the verification records with the change.
- Plugin approval: approve each plugin through your own review before it enters the internal store, including licensing and code review.
- Evidence to expect: an import log, artifact hashes, a bill of materials for each release and a record of who approved each import.
- Timing: confirm with your team how long an internal import and approval cycle takes, since it adds steps before any test upgrade begins.
What you need to provide before work starts
The fastest way to scope a Moodle upgrade is to hand over a complete inventory before the first call. Start with the current Moodle version and its install history, including every past point release and any earlier upgrades that were only partly tested. Pair that with the database engine and version, the PHP version and extensions in use, and the web server configuration, with the document root stated explicitly. The document root matters because from Moodle 5.1 it must point to the new /public directory, and a mismatch is one of the first things we check.
Next, provide a plugin and theme inventory that lists each component, its version, where it was obtained (the Moodle plugins directory, a vendor, an in-house repository or a local patch) and whether anyone has modified its code. For each plugin, ask the maintainer or check its listing to confirm whether a release exists for your target Moodle version. If none is published, the decision to replace, fork or drop it belongs to a named technical owner, and it should be made before the test plan is fixed. Also list every integration that depends on Moodle, such as SSO, HR or student information feeds, grade return and reporting, because each one needs a test case.
Access and ownership come next. Confirm that you can give us staging and production access, and describe the backup route, including where backups are stored, how long they are kept and how a restore is requested. Name one owner for technical decisions and one owner for academic acceptance, and agree a change window with both. Finally, provide a set of test accounts covering each role used on the site, along with course samples that include quizzes, assignments, groups and completion settings. These become the regression baseline, so their quality directly determines how much testing the upgrade needs.
Questions buyers ask about Moodle upgrades and support
How often do Moodle releases need to be upgraded?
Moodle ships a major release every six months, in April and October, and point releases every two months in February, April, June, August, October and December. Each major has its own support window, so the version you run matters as much as the cadence. Moodle 4.5 is a long-term support (LTS) release from 7 October 2024 with security support until 4 October 2027. Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027. Confirm the current table on the Moodle releases page before you set a plan.
Do Moodle LTS releases remove the need for frequent upgrades?
Partly. LTS releases give a longer security support window, so a site on an LTS line can wait longer between major moves. They do not remove the work. Point releases still arrive, PHP and database requirements still change between LTS lines, and a jump between LTS releases still needs plugin checks and testing. Moodle 4.5 has security support until 4 October 2027, and Moodle 5.3 is the next LTS, with general support until 4 October 2027 and security support until 1 October 2029. Plan your window around those dates and confirm them on the Moodle releases page.
How long does a Moodle upgrade take?
There is no fixed duration, because the answer depends on the size of the jump and what runs on top of core. The main drivers are your starting version (Moodle 5.1 requires sites to be on 4.2.3 or later, and Moodle 5.3 requires 4.4 or later), PHP and database changes, the number of installed plugins and custom code, the size of the database and moodledata storage, and how much regression testing your courses and integrations need. Ask for the duration in the written scope, with the test cycles and cutover steps it covers.
What drives the price of a Moodle support contract?
Support is a recurring cost, and the price follows the scope agreed in writing. The main components are the hours and response times covered, security patch handling, the number of Moodle releases you move through each year, plugin maintenance, and testing before each upgrade. Hosting and infrastructure are usually a separate cost paid to your cloud provider or data center. DeployOpen supports Moodle inside your infrastructure through retainers and does not publish prices, so a quote follows from the scope. Ask what is included, what is excluded, and what triggers extra work.
Can our own team upgrade Moodle without outside help?
Yes, many teams can, if they have Linux, PHP, database and Moodle administration skills and a staging environment that matches production. The core steps are confirming the target PHP and database versions, checking that your starting version meets the floor, moving the web server document root to the /public directory from Moodle 5.1, checking every plugin against the target release, and testing courses, grades and integrations. If you use the Classic theme, note that Moodle 5.3 removes it from core. Outside help adds the most value when the jump is large or the site is business-critical.
What happens to third-party Moodle plugins during an upgrade?
Each third-party plugin needs a version built for your target Moodle release, and the plugin listing shows which releases it supports. Confirm this before you upgrade, because a plugin that works on your current version may not run on the next. For example, the SAML2 plugin (auth_saml2) lists support for Moodle 2.7 through 5.1, so a move to a later release needs a check against its current listing. Custom plugins need code review, retesting and sometimes changes for updated core APIs. Remove or replace plugins that are no longer maintained.
How DeployOpen runs Moodle upgrades and support
DeployOpen plans and carries out Moodle upgrades and ongoing support for self-hosted sites in infrastructure you control. Each engagement starts with a written scope that covers the version path, platform requirements and plugin review before any change reaches production.
How we scope
- Confirm your current Moodle version and the target release, including whether an LTS or in-cycle major fits your support timeline.
- Check PHP, database and web server requirements for the target version against your current hosts before any work starts.
- Inventory installed plugins, themes and local customizations, and record compatibility status for each one in the written scope.
How we build
- Stand up a staging copy of production code, data and configuration so the upgrade is rehearsed on realistic conditions.
- Apply platform changes such as PHP upgrades, database version changes and web server document root adjustments, then run the upgrade and log each step.
- Test core workflows, enrolments, grading, SSO logins and scheduled tasks on staging, and fix plugin or theme breakages before cutover.
How we hand over
- Deliver an upgrade runbook with pre-checks, cutover steps, rollback steps and named owners for each stage.
- Document the final platform versions, plugin versions and configuration changes so your administrators can repeat the process later.
- Walk your administrators through the change log and the test results, and record any open items agreed in writing.
How we support
- Offer ongoing support after go-live as a retainer, with the response expectations and coverage hours written into the agreement.
- Monitor security releases and point releases that affect your installed version, and agree in writing which patches DeployOpen applies.
- Review plugin compatibility and platform requirements ahead of the next major release, so each future upgrade is planned rather than reactive.
