In a recent Moodle community forum thread, an administrator testing a 4.5 to 5.0 upgrade on a staging site watched it stop on a missing class. Moodle 5.0 had removed the PHP machine-learning backend, and the old site’s analytics setting still pointed at it. One stored setting, set years earlier, stopped the entire upgrade, and nothing in 4.5 warned about it.
That is the shape of the 4.x to 5.x jump. A Moodle 5.3 LTS upgrade is not an application update. It changes the platform underneath your courses, so the plan has to start from an inventory rather than a date. This guide covers the decisions to settle before any technical work begins.
I recently migrated my site to Mindfield from another host, and the experience couldn’t have been better. Mindfield kept working until they were certain that my site was operating as well as it was before, and they even helped clean up a few issues to improve my site’s performance – issues my prior host never mentioned. I also found Mindfield’s communication to be excellent. Before the migration, they prepared me for what to expect, and during the migration they kept me well-informed.
Jim Benedek
review Source: Google Reviews
Outline
- The Business Case: Why 5.3 LTS is the Target, and Why the Clock Already Started
- What Actually Changes Between 4.x and 5.3, The Compatibility Inventory
- The Upgrade Path and a Phased Rollout that Keeps the Site Running
- Training and Change Management: What People Will Actually Notice
- Resourcing Post-Upgrade Support
- Powering Your Moodle 5.3 LTS Upgrade with Expert Support
- Frequently Asked Questions (FAQs)
The Business Case: Why 5.3 LTS is the Target, and Why the Clock Already Started
For a site on 4.x, choosing the target comes down to one question: how long will the next version be supported? The dates answer it.
Where Each 4.x Site Stands Today
Major versions arrive every six months and an LTS every two years, per Moodle’s official release page.
| Moodle Release | Release Date | General Support End | Security Support End |
|---|---|---|---|
| 4.1 LTS | 28 Nov 2022 | 11 Dec 2023 | 8 Dec 2025 |
| 4.5 LTS | 7 Oct 2024 | 6 Oct 2025 | 4 Oct 2027 |
| 5.0 | 14 Apr 2025 | 20 Apr 2026 | 5 Oct 2026 |
| 5.1 | 6 Oct 2025 | 5 Oct 2026 | 19 Apr 2027 |
| 5.2 | 20 Apr 2026 | 19 Apr 2027 | 4 Oct 2027 |
| 5.3 LTS (Scheduled) | 5 Oct 2026 | 4 Oct 2027 | 1 Oct 2029 |
A site currently on Moodle 4.1 LTS needs immediate attention. Its security support ended on December 8, 2025. The site is already running without security fixes, so the business case is made; what remains is doing it deliberately.
Why 5.3 LTS Offers the Best Runway
A 4.5 LTS site has security support until October 4, 2027, which is a year of runway to do this deliberately. Stopping on an intermediate release buys far less:
- 5.0: security support ends October 5, 2026.
- 5.1: security support ends April 19, 2027.
- 5.2: security support ends October 4, 2027, the same day as 4.5 LTS, so it buys no runway and forces another major upgrade within a year.
- 5.3 LTS: security support runs to October 1, 2029.
In other words, one upgrade buys three years of cover. Cadence itself is settled in our article on the pros and cons of using the latest Moodle vs Moodle LTS, and 4.5 in our Moodle 4.5 LTS review.
The Urgency of Planning Before Release
5.3 LTS is scheduled for October 5, 2026, but every structural change in this jump has already shipped in 5.0, 5.1 or 5.2, and 5.3’s published requirements match 5.2’s. So the planning can start now, against a release you can already see.
Lessons from Moodle 5.2’s Point Releases
The experience with Moodle 5.2 offers a crucial lesson for upgrade planning. Moodle itself advised against upgrading to 5.2.2 (“Please do not upgrade to this version”) due to a regression where grade penalty offsets were applied twice. Users were urged to move to 5.2.3 as soon as possible, which also fixed scheduled tasks running twice.
This incident underscores that even stable releases can introduce critical regressions. Therefore, a strategic Moodle 5.3 LTS upgrade plan should target a specific, tested point release, not simply “the latest,” and include room to wait for a thoroughly vetted version.
What Actually Changes Between 4.x and 5.3: The Compatibility Inventory
Most of what changes between 4.x and 5.3 never appears on the upgrade screen. Each item below is a line in a release note and a decision for the organisation.
The Server Stack Upgrade
Moodle has to run on a newer stack before it can move at all:
- PHP: 8.3 minimum since 5.2. By contrast, 4.1 ran on PHP as old as 7.4 and topped out at 8.1.
- Database: PostgreSQL 16 and SQL Server 2019 since 5.2; MySQL 8.4 and MariaDB 10.11 since 5.0.
- Oracle: support removed entirely in 5.0.
So this is a hosting conversation first. On shared hosting, the stack can decide the whole timeline.
The Public Web Root Relocation
Starting with Moodle 5.1, the system introduced a new /public folder. This folder is intended to be the only directory publicly accessible from the web. Consequently, the web server’s document root must be reconfigured to point to this new location.
Moodle’s own notes warn that some sites may display directory listings or errors after the upgrade if this configuration is not completed. Additionally, certain third-party plugins might need to be relocated within this new structure. Therefore, this is a crucial change to the hosting configuration, not Moodle itself, requiring close coordination with your host.
Core Plugins Removed from Moodle 5.0
Moodle 5.0 removed these from core, and each needs a reinstall, replace or retire decision:
- Chat and Survey activities: courses still using them need a plan before the upgrade.
- Atto editor and CAS authentication: still available as separately maintained plugins.
- MNet: removed with all its plugins.
- PHP machine-learning backend: maintained separately; Python is now the default analytics backend.
The last one is the opening case. A stored setting that points at something removed can stop the whole upgrade, which is why the inventory has to cover settings, not just plugins.
Question Bank Migration
Moodle 5.0 fundamentally restructured how question banks operate. They are now managed as a new type of activity within Moodle. During the upgrade process:
- Course-level questions move to an automatically created shared bank specific to that course.
- Category-level questions migrate into a new course specifically created for that category.
- Site-level questions are moved to a shared bank located on the site home page.
Moodle’s documentation indicates that most migration problems on large question banks were resolved in 5.0.2. However, upgraded sites also require manual granting of question permissions for non-editing teachers, permissions that are default on new installations. For any organization where assessments are a core product, rehearsing this aspect of the Moodle 5.3 LTS upgrade is paramount.
For further guidance, consult our coverage of top Moodle question bank issues.
The Theme Framework Shift to Bootstrap 5
Moodle 5.0 saw the Boost theme upgraded to Bootstrap 5. This change included a temporary compatibility layer for third-party plugins. However, any custom or purchased theme built on the older Bootstrap framework will need careful assessment.
It must be confirmed as compatible with Bootstrap 5 or rebuilt to function correctly within the new environment. For more information on this, explore our articles on the Moodle Boost theme and its Bootstrap versions and managing custom Moodle themes.
The Scheduled Removal of the Classic Theme
According to Moodle’s development notes, the Classic theme is scheduled for removal from core in Moodle 5.3. On upgrade, compatible settings from Classic will migrate to Boost. However, presets and block positions will not be carried over.
An organization that wants to keep Classic has to install it separately, from Moodle’s own repository, before the upgrade. It is important to confirm this detail against the final 5.3 release notes. Our article on the Moodle Classic theme end of life provides further context.
Third-Party Plugins and Integrations
Two years between LTS releases is long enough for a plugin maintainer to stop. Moreover, three changes above can each break an older plugin:
- the new /public web root
- Bootstrap 5
- PHP 8.3
That makes the plugin inventory the first check against 5.3, not the last. See Moodle Marketplace and the plugins that were not migrated and Moodle plugin cleanup strategies.
Integrations sit on top of all of this: Moodle single sign-on, the student information or membership system, payments and reporting feeds. They usually fail quietly, so each one needs its own test.
The Upgrade Path and a Phased Rollout that Keeps the Site Running
The right plan depends on where the site starts, and a phased rollout keeps it running throughout.
Determining Your Moodle Upgrade Path
Moodle 5.3 can only be reached from 4.5 or later, and most owners do not know it:
- On 4.5 LTS: one upgrade, straight to 5.3.
- On 4.1 LTS: two upgrades, 4.1 to 4.5 (from 4.1.2 or later) and then 4.5 to 5.3, plus at least one server stack change.
For the first hop, see our guide on upgrading Moodle from 4.0 to a 4.x LTS version.
Strategic Phasing for Minimal Disruption
A phased strategy finds problems before live users do. The principles:
- Comprehensive Inventory First: Catalog all plugins, custom themes, integrations, removed activities in use, analytics settings, and the current server stack.
- Rehearsal on Staging: Perform a full upgrade rehearsal on a staging copy of your site, using real data. For example, the opening case of the analytics setting was found on staging, demonstrating its value.
- Iterative Fix and Re-rehearsal: Address any issues identified during the rehearsal. Then, repeat the staging upgrade process to confirm fixes and uncover any new conflicts.
- Production Window and Rollback: Schedule a production upgrade window with a clearly defined rollback position agreed upon in advance.
- Pilot Group Engagement: Involve a pilot group of real teachers or staff to test the upgraded staging copy. They can uncover usability issues that an administrator’s checklist might miss.
For testing, see our guidance on automated testing strategies for Moodle upgrades. Our articles on emergency backup and migration strategies for Moodle and how to fix Moodle upgrade issues cover the fallback position.
Timing Your Production Upgrade Window
The optimal time for a production upgrade should align with your organization’s internal calendar. This means avoiding term starts, exam periods, renewal deadlines, or peak enrollment times. Commit to a window well before 4.5’s security support ends on October 4, 2027. That way the decision stays a choice rather than a reaction to expiring support.
The Value of Waiting for a Stable Point Release
A .0 release is the first version most sites will ever run. The 5.2.2 notice shows that a point release can carry a regression in exactly the records an organization cares about.
Planning the production move for a later point release, one you have tested on a copy of the site, is therefore a legitimate choice rather than hesitation.
Training and Change Management: What People Will Actually Notice
Most of the jump is under the hood, but some of it lands on screen. Tell each group what changes for them.
Impacts for Teachers and Course Builders
Teachers and course builders will notice several key differences. Question banks now reside in a different place, requiring an adjustment to their workflow. The text editor experience will change for anyone still using the Atto editor, especially if it is not reinstalled as a separate plugin.
Furthermore, the Chat and Survey activities will be absent from the activity chooser. For sites previously using the Classic theme, the transition to Boost will mean blocks may appear in different positions within courses.
Changes for Learners and Members
Learners and members see a different look on Classic-theme sites. They also lose whatever a removed Chat or Survey activity did for them, so that needs a replacement or a retirement note.
Considerations for Administrators and Support Staff
Administrators and support staff need to know the new structure, the relocated plugins and the question permissions to grant on upgraded sites, because users will ask them first.
Principle of Targeted Communication
Tell each group what changes for them, before it changes, in their own terms. A short “what’s different” note per audience and a pilot group that has already seen it beat a long training programme. See also the importance of training and support after software is implemented.
Resourcing Post-Upgrade Support
The upgrade is not the end of the project. The first weeks are when the problems testing missed come to light.
Anticipating Quiet Failures
Most post-upgrade problems are quiet: scheduled tasks that stop running, notification emails that never send, integrations that stop carrying data, reports that return different numbers. Nothing errors, so decide in advance who is watching during the first weeks.
Establishing Before-and-After Evidence
To confidently determine if the upgraded site is functioning correctly, define key metrics that signify “the site still works” before the upgrade. These might include:
- Course completions
- Grade calculations
- Enrollments synced from external systems (SIS/membership)
- A key report run over a fixed date range
Capture these numbers before the upgrade, and then reproduce them on the new system to verify consistency. A simple login test only proves the site is up, not that the data and records have been preserved and are accurate.
Sustaining the Maintenance Rhythm
Moodle ships point releases every two months, LTS included, and some carry fixes that matter. For instance, Moodle 5.2.3 fixed both the grade penalty issue and scheduled tasks running twice.
Therefore, post-upgrade support is not a short-term, two-week project. Organizations must budget for an ongoing maintenance rhythm to apply these crucial updates. Our articles on Moodle maintenance strategy and a comprehensive guide to Moodle support offer further insights.
Clarifying Ownership and Responsibilities
A clear delineation of responsibilities is paramount for successful post-upgrade operations. Before the upgrade window, formally document who owns each aspect:
- The hosting provider owns the server stack and its compliance with Moodle’s new requirements.
- Your external partner or internal technical team owns the upgrade execution and plugin compatibility.
- Your organization owns the project calendar, all internal communications, and the final acceptance check of the upgraded site.
Powering Your Moodle 5.3 LTS Upgrade with Expert Support
A Moodle 5.3 LTS upgrade is a platform change, and the organizations that handle it well treat it as one. Mindfield Consulting audits your site against the 4.x to 5.3 inventory: server stack, plugins, theme, integrations and the removed activities still in use. We then plan the path and the window around your calendar and rehearse the upgrade on a copy of your real site. We stay on through the first weeks, when the quiet failures surface.
Frequently Asked Questions (FAQs)
This article may contain conceptual illustrations to help support the article content.
