Moodle 5.0 stopped receiving security fixes on 5 October 2026, the same day Moodle 5.3 LTS was released. If you are on 5.0 (or anything older than 4.5), you should plan an upgrade now. Most organisations that want stability should move to Moodle 5.3 LTS, which gets security fixes until 1 October 2029. Teams that want new features, including new AI providers, as soon as they ship can stay on the six-monthly track instead, but must budget for two upgrades a year. 5.3 needs PHP 8.3 or later and can only be upgraded to directly from Moodle 4.4 or later.
Key takeaways
- Moodle 5.0 is now fully unsupported: no bug fixes and no security fixes. Moodle 4.4 and 4.1 LTS lost all support in December 2025.
- Supported today: 4.5 LTS and 5.1 (security fixes only), and 5.2 and 5.3 LTS (fully supported).
- Standard releases get 18 months of security fixes. LTS releases get 36 months, so 5.3 LTS is covered until October 2029.
- Choose LTS if you value stability and fewer upgrade projects. Choose the six-monthly track if you need new features, such as new AI providers, quickly.
- 5.3 needs PHP 8.3+, PostgreSQL 17+, MySQL 8.4+ or MariaDB 11.4+. Check your server before you plan dates.
- If you are upgrading from 5.0 or earlier, the 5.1 /public directory change applies to you: your web server's document root must change.
- Always rehearse the upgrade on a copy of production first, with every plugin checked for a 5.3-compatible version.
What "end of support" actually means for your Moodle site
Every Moodle version gets two kinds of fixes for a fixed period: bug fixes for general core bugs, and bug fixes for security issues. When the second one stops, the version is unsupported. That is what happened to Moodle 5.0 on 5 October 2026. Its own release page now says it will not receive fixes for security risks and encourages sites to upgrade.
Your site does not stop working on the day support ends. Nothing switches off. The risk builds up over the following months, for three reasons:
- New vulnerabilities become public. Moodle shares security details with registered admins when it releases a fix, and makes them public a week later. From now on, every vulnerability found in code that 5.0 shares with supported versions gets fixed there, and not in 5.0. Your site keeps the hole, and the details are published.
- Plugins move on. Plugin developers test against supported versions. Over time, the plugins you depend on release updates you cannot install.
- Audits ask the question. If you hold ISO 27001 certification, or process personal data under India's DPDP Act, which expects reasonable security safeguards, "we run unpatched software holding learner records" is a finding waiting to happen. An LMS holds names, emails, assessment results and often compliance training records.
The good news: Moodle's release schedule is predictable, so you can plan this properly rather than react to it.
Which Moodle versions are supported today
All dates are from Moodle's official release and support table, as of 7 October 2026.
| Version | Released | Bug fixes end | Security fixes end | Status today |
|---|---|---|---|---|
| 4.1 LTS | 28 Nov 2022 | 11 Dec 2023 | 8 Dec 2025 | Unsupported |
| 4.4 | 22 Apr 2024 | 21 Apr 2025 | 8 Dec 2025 | Unsupported |
| 4.5 LTS | 7 Oct 2024 | 6 Oct 2025 | 4 Oct 2027 | Security fixes only |
| 5.0 | 14 Apr 2025 | 20 Apr 2026 | 5 Oct 2026 | Unsupported (as of this week) |
| 5.1 | 6 Oct 2025 | 5 Oct 2026 | 19 Apr 2027 | Security fixes only |
| 5.2 | 20 Apr 2026 | 19 Apr 2027 | 4 Oct 2027 | Fully supported |
| 5.3 LTS | 5 Oct 2026 | 4 Oct 2027 | 1 Oct 2029 | Fully supported |
How the cycle works. Moodle ships a major version every six months, in April and October, with point releases every two months. A standard release gets 12 months of bug fixes and 18 months of security fixes. A Long Term Support (LTS) release gets the same 12 months of bug fixes but 36 months of security fixes. The recent LTS releases are 4.1, 4.5 and now 5.3. Moodle also has a rule that matters for planning: an LTS always requires the previous LTS or later to upgrade from.
If you are on 4.5 LTS, you are covered for security until 4 October 2027, so you have a year. Use it to plan the move to 5.3 calmly rather than at the last minute, because that jump crosses every structural change described below.
LTS or the six-monthly track: how to choose
Once you are on a supported version, you have a real choice about how you stay there. Neither option is wrong. They suit different organisations.
The LTS track: upgrade roughly every two years
You move from one LTS to the next (4.5, then 5.3, then the following LTS) and apply point releases in between. Each major upgrade is a bigger project, because you cross several versions' worth of changes at once, but you do it far less often. This suits:
- Universities and schools that can only touch the platform between terms or semesters
- Regulated organisations (pharma, banking, healthcare) where every change needs validation, testing and sign-off
- Sites with a large set of third-party or custom plugins that each need checking
- Small teams with no dedicated Moodle administrator
The six-monthly track: upgrade every April and October
You take each new major version within its support window. Each upgrade is smaller, because only six months of changes arrive at once, but you do it twice a year. This suits:
- Teams that want new features as soon as they ship, especially AI
- Organisations with an in-house or partner team that already runs a regular release process
- Sites with a lean plugin set, where compatibility checks are quick
What you give up on LTS: features arrive in batches
Moodle's AI subsystem shows the trade-off clearly. It first shipped in 4.5, and nearly every release since has added to it: the Ollama provider for local models (5.0), DeepSeek and course- and activity-level AI controls (5.1), Google Gemini and Amazon Bedrock (5.2), and Anthropic Claude (5.3). A site that stayed on 4.5 LTS saw none of these for two years. It gets them all at once on 5.3. If waiting that long would hold your team back, the six-monthly track is worth its extra upgrade work. For the full picture of what core AI can and cannot do, see our guide to Moodle AI plugins.
LTS track (4.5 → 5.3 → next LTS)
- One major upgrade about every two years
- 36 months of security fixes per version
- Bigger upgrade projects that cross several versions at once
- New features arrive in batches, up to two years late
- Best for regulated, academic and plugin-heavy sites
Six-monthly track (every April and October)
- Two smaller upgrades every year
- 18 months of security fixes per version
- Less change per upgrade, so less to test each time
- New features, including AI providers, as soon as they ship
- Best for teams with a regular release process
Your upgrade path, by the version you run today
Moodle 5.3 can only be upgraded to directly from Moodle 4.4 or later. Older sites need an intermediate step. Moodle 4.5 can be reached from 4.1.2 or later.
| You are on | Route to a supported version | Watch out for |
|---|---|---|
| 4.1 LTS or older | Upgrade to 4.5 LTS first (needs 4.1.2+), then to 5.3 | Two projects. Plan the PHP and database upgrades along the way. |
| 4.2 or 4.3 | Upgrade to 4.4 or 4.5, then to 5.3 | Same as above: an intermediate step is required. |
| 4.4 | Directly to 5.3 | PHP 8.3 and newer databases; every 5.0–5.3 change at once. |
| 4.5 LTS | Directly to 5.3 (deadline: October 2027) | The /public restructure, Bootstrap 5 and Atto removal all land together. |
| 5.0 (unsupported now) | Directly to 5.3, as soon as you can | The /public restructure from 5.1, and PHP 8.3. |
| 5.1 (security fixes only) | To 5.3 before April 2027, or to 5.2 if you stay on the six-monthly track | PHP 8.3 is required from 5.2 onwards. |
| 5.2 | Choose: stay on the six-monthly track, or move to 5.3 LTS | Small jump. A good moment to decide your track. |
Moodle 5.3 requirements: check your server first
Server requirements are where upgrade plans most often slip, because a PHP or database upgrade is a project of its own. These are the minimums from the official release notes:
| Version | PHP | PostgreSQL | MySQL | MariaDB | SQL Server |
|---|---|---|---|---|---|
| 5.3 LTS | 8.3 – 8.4 | 17 | 8.4 | 11.4.0 | 2019 |
| 5.2 | 8.3 – 8.4 | 16 | 8.4 | 10.11.0 | 2019 |
| 5.1 | 8.2 – 8.4 | 15 | 8.4 | 10.11.0 | 2017 |
| 5.0 | 8.2 – 8.4 | 14 | 8.4 | 10.11.0 | 2017 |
| 4.5 LTS | 8.1 – 8.3 | 13 | 8.0 | 10.6.7 | 2017 |
Sources: 5.3, 5.2, 5.1, 5.0 and 4.5 release notes. PostgreSQL 17 and MariaDB 11.4 are new minimums in 5.3. 5.3 also needs 64-bit PHP, the sodium extension and max_input_vars of at least 5000. Oracle has not been supported since 5.0.
If you are planning server changes anyway, it is a good time to review sizing. Our guide to Moodle server architecture and concurrent users and our PHP, OPcache and MySQL tuning guide cover that in detail.
The changes that break sites when you cross versions
If you are jumping from 4.5 or 5.0 to 5.3, you inherit every change below in one go. These are the ones that cause most failed or delayed upgrades.
The /public directory (from 5.1)
Since 5.1, all web-accessible files live in a /public folder. Your web server's document root must point to moodle/public, and the upgrade will not go ahead until that is configured. config.php stays in the Moodle root. Third-party plugins must be placed in the new location. Sites that were not reconfigured can show directory listings or errors. Moodle's new routing also needs a web server rule (FallbackResource /r.php on Apache, or a try_files rule on nginx), and since 5.2 the environment check tests for it.
Removals in 5.0
Moodle 5.0 removed the Atto editor, the Chat and Survey activities, Oracle support, CAS authentication, all MNet plugins and SQLite, and raised the minimum PHP to 8.2. The Boost theme moved to Bootstrap 5, with a compatibility layer for older Bootstrap 4 code. Custom themes are where this usually shows up.
Changes in 5.1 and 5.2
5.1 removed the Section links block and turned off the Social course format by default. 5.2 removed the Activities block and the MimeTeX filter option (sites must switch to MathJax), removed subsection descriptions and pages, and made forced login the default on new installs. After upgrading, subsection descriptions stay hidden until an admin runs the migrate or delete task.
Changes in 5.3
The Classic theme has been removed from core, notifications for new logins are on by default, and MoodleNet integration is deprecated. If your site has a vendor/ directory, you need to run composer install --no-dev --classmap-authoritative as part of the upgrade.
What is new in Moodle 5.3 LTS
It is not only maintenance. From the 5.3 release notes, the changes most sites will notice:
- A visual refresh across the site: new font, centred layout, inline search, and the user's name next to their avatar. There is also an experimental dark mode for Boost.
- Linear course navigation, with Previous and Next buttons through activities, controlled by a site setting.
- Learning outcomes: a first version of constructive alignment, including backup and restore support.
- Assignment marking workflows, with separate feedback per marker and sample marking.
- Quiz due dates, and a configurable delay before quiz statistics are calculated.
- AI: an Anthropic Claude provider, and reporting on AI use per user.
- Report builder: SQL-based data sources and more time-based aggregations.
- Admin quality of life: courses delete in the background, and scheduled tasks can be run immediately in the background.
Because 5.3 is an LTS, these are the features your users will live with until the next LTS, so it is worth switching on the ones you want during the upgrade rather than after.
- 1Inventory what you run
Record your exact Moodle version, PHP and database versions, theme, and every additional plugin (Site administration > Plugins > Plugins overview > Additional plugins).
- 2Check every plugin for a 5.3 version
Look up each plugin in the Moodle plugins directory. If one has no compatible version, decide now: replace it, fund an update, or uninstall it. Moodle's own guidance is to uninstall plugins that have no version for the new release.
- 3Upgrade the server stack
Move to PHP 8.3 or 8.4 and a supported database version, and set the document root to moodle/public. Do this on the copy first.
- 4Rehearse on a copy of production
Restore a recent copy of the code, moodledata and database to a staging server and run the full upgrade there. Moodle's documentation is explicit: test the upgrade first on a copy of your production site.
- 5Test what your users actually do
Log in as a learner, a teacher and an admin. Launch SCORM packages, attempt a quiz, submit an assignment, run your key reports and check your theme on mobile.
- 6Back up and freeze
Set an upgrade key, back up code, moodledata and the database, put the site into maintenance mode, and wait for cron to finish.
- 7Run the upgrade
Check Site administration > Server > Environment, then run the upgrade. For large sites, use the command-line upgrade rather than the browser.
- 8Verify and tidy up
Purge all caches, run any migrate or delete tasks flagged after upgrade, check cron and scheduled tasks, and watch error logs for the first week.
Give yourself a rollback plan
Before the production upgrade, write down exactly how you would restore yesterday's backup and how long it takes. A rehearsal on a copy tells you the upgrade works. A rehearsed rollback tells you a bad day stays a bad day, not a bad week.
Want the upgrade handled for you?
edzlms runs on Moodle, and we manage upgrades for the platforms we host: plugin compatibility checks, staging rehearsals, server changes and post-upgrade testing, scheduled around your term or audit calendar.
Frequently asked questions
When did Moodle 5.0 support end?
Moodle 5.0 stopped receiving security fixes on 5 October 2026. Its general bug fixes had already ended on 20 April 2026. 5.0.11 was the final release.
Is Moodle 5.3 an LTS release?
Yes. Moodle 5.3, released on 5 October 2026, is a Long Term Support release. It gets bug fixes until 4 October 2027 and security fixes until 1 October 2029.
Can I upgrade directly from Moodle 4.5 or 5.0 to 5.3?
Yes. Moodle 5.3 can be upgraded to directly from 4.4 or later, which includes 4.5 and 5.0. Sites on 4.3 or older need an intermediate upgrade to 4.4 or 4.5 first.
What PHP version does Moodle 5.3 need?
PHP 8.3 or 8.4, 64-bit, with the sodium extension and max_input_vars of at least 5000. PHP 8.2 is not enough, even though 5.0 and 5.1 accepted it.
How long is Moodle 4.5 LTS supported?
Moodle 4.5 LTS gets security fixes until 4 October 2027. Its general bug fixes ended on 6 October 2025.
Should we choose LTS or upgrade every six months?
Choose LTS if stability, validation effort or a large plugin set make upgrades expensive. Choose the six-monthly track if you want new features, including new AI providers, as soon as they ship and can run two smaller upgrades a year.
What is the /public folder change in Moodle?
From Moodle 5.1, all web-accessible files live in a /public directory. Your web server's document root must point to moodle/public, config.php stays in the Moodle root, and the upgrade will not proceed until the web server is reconfigured.
What happens if we keep running an unsupported Moodle version?
The site keeps working, but no new security fixes are released for it. Vulnerability details for supported versions are made public a week after each fix, plugins gradually stop supporting your version, and auditors may treat it as a finding.
Plan your move to 5.3 LTS
If you are on 5.0, treat this as urgent but not an emergency: rehearse the upgrade on a copy this month and schedule production soon after. If you are on 4.5 LTS, you have until October 2027, which is enough time to do it properly. Either way, decide your track before you upgrade, because it changes how you plan the next two years.
For the step-by-step mechanics of a Moodle upgrade, see our complete Moodle upgrade guide. If you are thinking about moving off a self-managed Moodle altogether, the Moodle migration guide covers that.