Quick answer: A reliable Moodle upgrade is a sequence of evidence gates. If any gate fails—requirements, compatibility, restore testing or functional validation—production should wait. This checklist is designed to be printed or copied into a change ticket.
Before staging
- Record Moodle, PHP, database and operating-system versions.
- Export a full plugin and theme inventory.
- Confirm the direct upgrade path begins at Moodle 4.4 or later.
- Check disk capacity and maintenance-window ownership.
- Document DNS, email, cron, cache and storage dependencies.
On staging
- Restore recent database, moodledata and code backups.
- Configure the document root for
public/. - Install only verified 5.3 plugin and theme packages.
- Run the upgrade with logging enabled.
- Test realistic courses and all critical roles.
Before production
- Approve a written rollback trigger and owner.
- Notify users of the maintenance window.
- Wait for active cron and queued jobs to finish.
- Take fresh, timestamped backups and verify them.
- Enable maintenance mode and stop cron.
After the upgrade
- Run cron manually once and inspect failures.
- Purge Moodle and opcode caches.
- Test SSO/login, enrolment, email, quizzes, assignments and backups.
- Review theme layouts on desktop and mobile.
- Monitor logs, database load and PHP errors before closing the change.
Rollback is part of the checklist
A backup is not a rollback plan until someone has restored it. Define the point at which you stop troubleshooting and restore the previous database, moodledata and code as a matched set.
Related Moodle 5.3 guides
- Moodle 5.3 LTS: what is new?
- How to upgrade to Moodle 5.3
- Moodle 5.3 server requirements
- Moodle 5.3 theme compatibility checklist
Frequently asked questions
When is the checklist complete?
Only when the staging upgrade, restore test and critical workflow tests have documented results and owners.
Can course backups replace a site backup?
No. Course backups do not replace matched backups of the site database, moodledata and application code.
How long should rollback assets be kept?
Keep them until production has completed normal traffic, cron, backup and teaching cycles without a critical regression.
When to bring in specialist help
Use an experienced Moodle administrator or hosting engineer when the work changes database major versions, authentication, production routing, custom plugins or a heavily modified theme. Record the change, test it away from production and keep a named rollback owner.
Final recommendation
Use a staging site, rely on version-specific evidence and keep a tested rollback path. Moodle 5.3 is a strong long-term target, but a controlled upgrade is more valuable than an early upgrade that breaks teaching workflows.
Source check: Verified on 21 October 2026 against official Moodle upgrading guidance and Moodle 5.3 release requirements.
