Fixed-price Moodle upgrades to 5.3 LTS.

Is your Moodle version still supported?

Moodle publishes a fixed support calendar for every release. Standard releases get about 12 months of general support (bug and security fixes) and another six months of security fixes only. Long-term support (LTS) releases get three years of security fixes. Once security support ends, newly disclosed vulnerabilities are not patched for that version. For a site holding student records, grades and assessment data, that is the point where an upgrade stops being optional.

Not sure which version you run? Our free Moodle version checker reads it from public files in a few seconds, with no login.

Which upgrade path do you need?

Moodle only upgrades from a minimum starting version. Moodle 5.2 and 5.3 require the site to be on Moodle 4.4 or later before the upgrade runs. That single rule decides how much work your upgrade involves.

From Moodle 4.1, 4.2 or 4.3

Two hops: first to 4.5 LTS, then to 5.3 LTS. Each hop runs Moodle’s database upgrade steps, and the PHP requirement changes between them (4.5 needs PHP 8.1; 5.3 needs PHP 8.3), so the server usually changes during the project. We run both hops on staging and you see one test report for the end state.

From Moodle 4.4, 4.5, 5.0, 5.1 or 5.2

One hop, directly to 5.3 LTS, provided the server meets the new requirements: PHP 8.3 or 8.4, and a supported database version. Most of the effort goes into the plugins and the theme, not Moodle core.

Any site on Oracle

Oracle support was removed in Moodle 5.0. The database has to be migrated to PostgreSQL or MySQL/MariaDB before a 5.x upgrade. We treat this as a Complex/Rescue engagement because the data migration needs its own verification.

What usually breaks in a Moodle 5.x upgrade

Moodle core upgrades are well tested. Problems almost always come from what sits around core:

• The new /public directory. From Moodle 5.1, web-accessible files live in a public folder and the web server’s document root must point to it. Sites that skip this step see directory listings or errors after upgrading.
• Plugins installed in the old locations. Plugins have to sit inside the new structure and be replaced with versions built for the target release. Abandoned plugins with no 5.x build must be replaced or retired.
• Custom themes. Child themes of Boost generally survive with template and SCSS fixes. Classic-based themes need more work, because Moodle has removed the Classic theme from core.
• PHP and database versions. PHP 8.3 is required for 5.2 and 5.3, and database minimums have risen (for example MySQL 8.4). Older servers often need replacing rather than patching.
• Local customisations. Core code edits made years ago (“core hacks”) are overwritten by an upgrade. We find them by comparing your code with stock Moodle before anything changes.

How a UTSL upgrade runs

1. Health Check ($390, 5 working days). We record the exact version, PHP, database, theme and every installed plugin, then rate each one red, amber or green against the target release. You get a fixed price for your site. The fee is credited in full if you go ahead.
2. Staging clone. A full backup and a copy of the code, database and moodledata on a separate environment.
3. Upgrade and audit on staging. Core, plugins and theme are upgraded together. Anything that fails is fixed, replaced or flagged for your decision.
4. Test report and rollback plan. We test logins, enrolment, course pages, quizzes, assignments, grades and your critical plugins, and write down exactly how we would roll back at cutover.
5. Go-live. A scheduled cutover in a window you choose (outside exam periods), followed by monitoring. If something goes wrong at cutover, we roll back rather than leave you on a broken site.

How much does a Moodle upgrade cost?

UTSL publishes fixed prices rather than hourly estimates, so you know the cost before work starts:

Payment is 50% upfront and 50% at go-live. If the work turns out to be bigger than the Health Check showed, we agree a revised fixed price before doing the extra work. After go-live, a Moodle Care Plan keeps the site patched so the next upgrade is smaller.

Pre-upgrade checklist for your team

• Pick a go-live window away from enrolment peaks and exam periods.
• List the plugins and integrations the business cannot run without (SSO, payment, video, proctoring, SIS sync).
• Confirm who can approve the staging test report on your side.
• Check hosting: can the server run PHP 8.3 and the required database version, or does it need replacing?
• Tell staff and learners about the maintenance window a week in advance.