Moodle 5.3 LTS Is Current: Check Your Upgrade Stack
Moodle 5.3 LTS is now listed as a current stable release, but its long support window does not make the upgrade automatic. Site owners first need to clear a new platform floor, check plugins and themes, and account for structural changes introduced earlier in Moodle 5.x.
Moodle released 5.3 on 5 October 2026. It is a released branch to assess now, rather than a future package to wait for. Moodle 5.2 also remains a current stable branch, while 4.5 LTS continues to receive security fixes. The right migration target depends on the existing system and its dependencies, as well as the length of support available.
Moodle’s table and its summary sentence disagree
Moodle’s central release table marks 5.3 LTS as current stable, with an initial release date of 5 October. The dedicated Moodle 5.3 release page gives the same release date.
However, the text immediately above the table still says Moodle 4.5 is the most recent LTS and 5.3 will be the next LTS. That sentence is stale relative to the table and the dedicated page. An upgrade decision should use the dated 5.3 record and current support table while recognising the documentation inconsistency.
The support clock has changed for 5.1 sites
Moodle 5.3 receives general core bug fixes until 4 October 2027 and security fixes until 1 October 2029. That three-year security horizon is the main planning value of the new LTS branch.
Moodle 5.1 has moved into security-only support. Its general bug-fix period ended on 5 October 2026, while security support continues until 19 April 2027. The branch is therefore not wholly unsupported today, but ordinary core bugs no longer have the same maintenance path. The 5.1 release page now encourages administrators to move to a supported version for general fixes.
The BlackTree Moodle lifecycle record reflects the vendor dates and separates the nearer 5.1 security boundary from the longer 5.3 window. Contracts for hosting, plugins and managed support can impose their own timelines, so the upstream dates are a baseline rather than a substitute for those agreements.
Clear the application and PHP gate first
Moodle documents direct upgrades to 5.3 from Moodle 4.4 or later. A site on an older branch should not assume it can jump straight to 5.3. It needs a supported intermediate path based on Moodle’s upgrade guidance and its own hosting arrangement.
The minimum PHP version is 8.3.0, and PHP 8.4 is also supported. Moodle requires 64-bit PHP, the sodium extension and a max_input_vars setting of at least 5000. Check the web and command-line environments separately because scheduled tasks and upgrade commands may use a different PHP binary or configuration from the web service.
Record the current Moodle version, PHP version and extensions before choosing a maintenance window. If the platform fails any minimum, resolve that dependency as its own controlled change and keep a tested restoration route. Combining an application upgrade, PHP replacement and database migration into one untested cutover makes failure diagnosis and rollback harder.
The database floor may be the larger project
Moodle 5.3 raises PostgreSQL to version 17 and MariaDB to 11.4.0. Its other documented minimums are MySQL 8.4, Aurora MySQL compatibility version 8.0 and Microsoft SQL Server 2019. For Aurora, Moodle says compatibility checks should use standard MySQL version numbers rather than Aurora’s internal 3.x numbering.
Oracle Database has not been supported since Moodle LMS 5.0. An Oracle-backed site is therefore looking at a database migration as well as an LMS upgrade. Treat that as a separate architecture decision with data validation, performance testing and a restore plan.
Do not read a minimum version as proof that a particular managed database configuration, extension set or high-availability design will work unchanged. Confirm the exact service version and driver support in a representative test environment before touching production.
Check plugins, themes and the web root
Inventory every contributed plugin and theme, including disabled components that remain on disk. Confirm that maintainers support Moodle 5.3, note abandoned dependencies and test the functions that matter to teaching, enrolment, authentication, reporting and scheduled tasks. Moodle 5.3 also removes the Classic theme from core, which makes a theme dependency review particularly important.
Sites moving from Moodle 5.0 or earlier should also account for the /public directory structure introduced in Moodle 5.1. The 5.1 notes warn that the web server document root must point to that directory and that existing plugins may need to be moved into the appropriate location. Use the current 5.3 upgrade guide for the exact path rather than assuming an older deployment layout will continue to work.
Check dependencies and course content as well as the server
The current 5.3 upgrade guide, last edited on 22 October, adds a dependency check that belongs in the rehearsal. Where the Moodle root already contains a vendor/ directory, the guide says to refresh Composer-managed dependencies after replacing the source and before running the upgrade. Composer is otherwise optional in 5.3, except for features such as the new OAuth 2 Server. Do not assume either that every installation needs the same step or that an existing dependency directory can safely be left untouched.
Check teaching content too. The guide says the Activities block is removed, so courses or dashboards using it lose that block. Existing subsection descriptions are not automatically migrated: they remain hidden until an administrator runs the relevant migration task. It also identifies removal of MimeTeX and recommends MathJax for sites that used it to render mathematical notation. These are reasons to involve course owners in the test, rather than treating a successful server start as the whole acceptance check.
A complete recovery copy needs the Moodle software, uploaded files and database. Rehearse with a copy of the production site, then check the resulting course content and integrations as well as the upgrade result. This report reviews the documented requirements and changes; it does not claim that a particular Moodle installation has been upgraded or tested.
A practical 5.3 readiness sequence
- Confirm the current Moodle branch and whether a direct upgrade to 5.3 is supported.
- Record PHP, required extensions, database engine and exact versions.
- Review the
/publicweb-root change if the site has not already adopted the directory layout introduced in 5.1. - Inventory plugins and themes, then verify 5.3 support with their maintainers.
- Restore the software, uploaded files and database into an isolated environment, check any Composer dependency step, and rehearse the upgrade there.
- Validate login, enrolment, course access, affected blocks and subsection content, scheduled tasks, integrations and rollback before approving production work.
Moodle 5.3 LTS offers the longest current security runway, while 5.1 now has a short, security-only horizon. The useful decision is therefore not simply whether to adopt 5.3. It is whether the existing Moodle branch, PHP runtime, database, plugins and deployment layout can cross the documented gates on a controlled schedule.
