Engineering Manual • Upgrades

Upgrading to Moodle 5.3 LTS, Without the Horror Stories.

Most upgrade disasters are sequencing errors: the wrong jump, an unaudited plugin, a PHP version the target Moodle never supported. This guide is the exact order of operations we run — audit first, rehearse on staging, then upgrade in supported steps.

By Baber Sheikh, Tech Lead at LMSOps · Published October 17, 2026 · Updated October 17, 2026

The short answer: Upgrade to Moodle 5.3 LTS — the long-term-support release (October 2026) with security fixes to October 2029. You must already be on Moodle 4.4 or later to jump; older sites step through 4.5 first. Your server needs PHP 8.3+ and MariaDB 11.4+ or PostgreSQL 17+. Audit every plugin for a 5.3-compatible release before you start, rehearse the full upgrade on a staging clone, and never upgrade production first.

Step 1: Respect the upgrade sequence

Moodle only upgrades across supported jumps. Skipping versions is how databases end up half-migrated: the upgrade code for intermediate versions never runs, and the failure often surfaces weeks later as corrupt gradebook data.

From 3.9  -> 3.11 -> 4.1 -> 4.5 -> 5.3 LTS
From 4.0  -> 4.1 -> 4.5 -> 5.3 LTS
From 4.4+ -> 5.3 LTS directly
From 4.5  -> 5.3 LTS directly

Check your current version and the exact path before anything else:

grep "\$release" version.php
# or in the admin UI: Site administration > Notifications

Step 2: Get the environment right first

Moodle 5.3 requires PHP 8.3 or later (8.4 is also supported), plus MariaDB 11.4+, MySQL 8.4+ or PostgreSQL 17+. The database minimums rose in 5.3 — shared hosts running older MariaDB are the most common blocker. Verify the environment report on your staging clone, not from memory:

php -v
php -m | grep -E "intl|sodium|gd|zip|xmlreader"
# Admin check: Site administration > Server > Environment

PHP extensions Moodle needs: intl, sodium, gd, zip, curl, openssl, mbstring, xmlrpc is gone (removed in 4.1+)
max_input_vars of 5000 — the default 1000 breaks large gradebook and quiz pages
OPcache enabled — the single biggest free performance win on most hosts

Step 3: Audit plugins before you touch the database

Plugins cause most failed upgrades. For every installed plugin, confirm a release exists for 5.3 (the version.php of the plugin states its supported range). Anything abandoned gets one of three verdicts: replace, fork-and-patch, or remove — decided before upgrade day, not during it.

# List third-party plugins and their versions
php admin/cli/cfg.php --component=moodle --name=version
ls mod/ blocks/ local/ theme/ | sort

Put the site into maintenance mode and take two backups — database and moodledata — stored off the server. An upgrade you cannot roll back is not a plan.

php admin/cli/maintenance.php --enable
mysqldump -u USER -p DBNAME > pre-upgrade.sql
tar -czf moodledata-backup.tar.gz /path/to/moodledata

Step 4: Run the upgrade on staging, then production

Run the entire upgrade on a staging clone with a copy of production data. Time it. Click through the five flows that matter: login, a quiz attempt, a file download, gradebook, and cron. Only then schedule production.

# On the clone, with the new code in place:
php admin/cli/upgrade.php --non-interactive
php admin/cli/cron.php
php admin/cli/maintenance.php --disable

After go-live, watch the task logs and error log for 48 hours. Database tuning that pays off immediately: convert MySQL/MariaDB tables to Barracuda/utf8mb4 if you have not already, and confirm the environment report is fully green.

Step 5: When staying on 4.5 LTS makes sense

4.5 LTS is still a supported line — security fixes run to October 2027 — and for sites mid-ladder it remains the natural intermediate stop before 5.3. If a critical plugin has no 5.3 release yet, landing on 4.5 and waiting one cycle is a defensible call. But for any site that can move, 5.3 is the destination: it is the LTS now, with security cover to October 2029. Decide by your plugins, not by the version number's shine.

Frequently asked questions

How long does a Moodle 5.3 upgrade take?

The CLI upgrade itself often runs in minutes. The real work is the audit and staging rehearsal: most sites we upgrade complete end-to-end within a few days, with the production cutover inside a one to two hour maintenance window.

Can I upgrade from Moodle 3.9 straight to 5.3?

No — and attempting it is the classic way to corrupt a site. The supported path is 3.9 to 3.11, then 4.1, then 4.5, then 5.3. Each intermediate step runs database migrations the direct jump skips.

What PHP version does Moodle 5.3 need?

PHP 8.3 minimum; 8.4 is also supported. If your host caps PHP below 8.3, the honest fix is moving hosts first — which is a standard $300 migration.

What if a plugin has no 5.3 version?

Three options: replace it with a maintained equivalent, have it patched forward (we do this as plugin rescue work), or remove it if usage data says nobody relies on it. What you cannot do is ignore it — the upgrade will either block or break quietly.

How much does LMSOps charge for an upgrade?

A fixed $200 for a standard upgrade, quoted after a free audit of your version, plugin count and data size. Broken-upgrade rescue starts with a $150 emergency diagnosis.

About the author

Baber Sheikh is the senior Moodle engineer and Tech Lead behind LMSOps — deployment, migration, upgrades and custom plugin work for schools, training providers and universities, at fixed published prices.

Want the upgrade done for a fixed $200?

Send us your current Moodle version and plugin list. We audit free, quote in writing, and rehearse on staging before your production site is touched.

Audit My Upgrade Free

The service page: Moodle upgrade services · 3.5 to 5.x upgrade playbook