Moodle™ Upgrade Checklist

Check whether your Moodle version is still in support or already end-of-life

Moodle 4.4 reached end-of-life in December 2025; 4.5 is the current LTS. An end-of-life version receives no security patches at all.

Confirm your PHP version is still receiving security updates

Running Moodle on an end-of-life PHP (e.g. 8.1 after its EOL) means the whole stack is exposed, even if Moodle itself is current.

Cross-check your version against the published Moodle security advisories

The 2025 advisories include remote-code-execution and SQL-injection fixes. If you have not patched since, assume you are exposed.

Audit installed plugins for ones that are abandoned or no longer maintained

An unmaintained plugin is a standing vulnerability and often the single blocker that stops you upgrading at all.

Decide your target version: latest LTS for stability, or latest release for newest features

LTS (4.5) gets security fixes the longest — the safest target for most organisations that upgrade infrequently.

Determine your current Moodle version and the supported upgrade path

Moodle only supports upgrading from specific versions (e.g. to 4.5 you must run 4.1 or later). Check the release notes for your target version.

Verify server requirements: PHP version, database version, and required PHP extensions

Each major release raises minimums. Admin → Server → Environment runs this check for the new version automatically.

Make a complete inventory of installed plugins and their compatibility with the target version

Uninstall plugins you no longer use before upgrading — every plugin is a potential blocker.

Identify custom code: theme modifications, core hacks, and bespoke plugins

Core modifications are the most common cause of failed upgrades. Diff your codebase against a clean Moodle release to find them.

Plan a full backup strategy: database, moodledata, and code

Test that the backup can actually be restored — an untested backup is not a backup.

Set up a staging environment that mirrors production

Run the full upgrade on staging first and time how long it takes

The measured duration determines your production maintenance window.

Smoke-test core flows: login, course access, assignment submission, grading, backups

Verify every third-party plugin works, or has an updated compatible release installed

Check the theme on desktop and mobile, including custom layouts and branding

Test all integrations: SSO/LDAP/OAuth, LTI tools, web services, and external enrolment

Authentication breakage locks out every user at once — test with real accounts from each auth method.

Confirm scheduled tasks and cron run cleanly after the upgrade

Compare page-load performance before and after on representative courses

Announce the maintenance window to users well in advance

Pick a low-usage moment — your Moodle analytics show exactly when that is.

Enable maintenance mode and take a fresh, final backup

Run the upgrade, then walk through the same smoke tests as on staging

Have a tested rollback plan ready with a clear go/no-go decision point

Monitor error logs and support tickets closely for the first week

Review the deprecation log and plan fixes for custom code before the next upgrade

Fixing deprecations now is what makes the next upgrade cheap.

Inform users about relevant new features so the upgrade delivers visible value

Document versions, settings, and lessons learned for the next cycle