Upgrading Moodle 4.5 to 5: A Real-World Checklist

Anyone needing to upgrade Moodle 4.5 to 5 today faces a bigger decision than it seems: the right destination, the accompanying database, and the public folder that changes the web server. Moodle 5.3 LTS was released on October 5, 2026, and the security window for 4.5 closes in October 2027. This is the checklist I follow, from inventory to rollback plan.

TL;DR

• Destination: Go for 5.3 LTS (security until 10/01/2029). Moodle 5.2 only has security until 10/04/2027, the same date as 4.5: you'd do all the work without gaining a single day of support.
• Biggest Blocker: The database. Moodle 5.3 requires MariaDB 11.4, PostgreSQL 17, or MySQL 8.4, and PHP 8.3. Most servers running 4.5 do not meet these requirements.
• Most Common Breakage: The /public folder (since 5.1), the mandatory router (r.php), and third-party plugins that need to be moved and updated.
• Rollback: Moodle does not downgrade. Rolling back means restoring code, moodledata, and the database from the exact same moment. Without these three, there is no Plan B.
• When: Stage now, go live in production after 5.3.1 (expected December 7, 2026) and outside of exam week.

I've managed Moodle environments since 2008 and have guided institutions through several LTS cycles. The difficult part of upgrading is never the upgrade command itself. It's the server that hasn't been updated in years, the plugin a vendor abandoned, and the lack of a tested rollback path. This guide addresses these issues for those responsible for an institution's LMS (Learning Management System): EAD or IT coordination.

Where to Upgrade Moodle 4.5 to 5 in 2026: The Calendar Decides

LTS stands for Long-Term Support. Moodle releases two versions per year, in April and October, and one out of every three is an LTS. Moodle 4.5 is the LTS from October 2024. The next is 5.3, just released. The dates below are published on the official Moodle releases page:

Version	Release Date	General Fixes Until	Security Until
4.5 (LTS)	10/07/2024	10/06/2025	10/04/2027
5.1	10/06/2025	10/05/2026	04/19/2027
5.2	04/20/2026	04/19/2027	10/04/2027
5.3 (LTS)	10/05/2026	10/04/2027	10/01/2029

The important takeaway: Moodle 4.5 has not received common bug fixes since October 2025, only security patches. And 5.2, which many still consider "the stable version," loses security on the same day as 4.5.

Therefore, when someone asks me to upgrade Moodle 4.5 to 5 right now, the answer is almost always 5.3 LTS. A direct jump is supported: 5.3 accepts upgrades from Moodle 4.4 or higher, according to the 5.3 release notes. There is no mandatory intermediate step.

When It Makes Sense to Stop at 5.2

Almost never. The exception is an institution that needs a 5.2 feature immediately, has a critical plugin that hasn't yet declared compatibility with 5.3, and is willing to repeat the process in 2027. Otherwise, it's migrating twice to get to the same place.

Requirements: The Server Running 4.5 Rarely Runs 5.3

Here lies the number one reason for project delays. Requirements have increased with each release since 4.5, and 5.3 has raised database requirements again. Comparing the official minimums:

Component	Moodle 4.5	Moodle 5.3 LTS
PHP	8.1.0	8.3.0 (8.4 supported)
MariaDB	10.6.7	11.4.0
PostgreSQL	13	17
MySQL	8.0	8.4
SQL Server	2017	2019
Oracle	19c	not supported (since 5.0)
Upgrade from	4.1.2	4.4

Sources: 4.5 and 5.3 release pages.

Anyone upgrading Moodle 4.5 to 5 needs to look at the database first, as this is where institutions often get caught off guard. Those who upgraded to 5.0 or 5.1 in 2025 moved to MariaDB 10.11 and thought the issue was resolved. For 5.3, the minimum became 11.4.0. For PostgreSQL, the floor was raised to version 17.

The Good News: The Database Calendar Also Improves

MariaDB 11.4 is supported until May 29, 2029, and PostgreSQL 17 until November 8, 2029, according to endoflife.date. This means the new database aligns with the end of 5.3 LTS support. PostgreSQL 14, however, loses support on November 12, 2026, and MariaDB 10.6 already lost it in July 2026. If your server is running these, the problem predates Moodle.

Three PHP Requirements That Can Break Your Installation

• Only 64-bit PHP. Rare on Linux, common on legacy Windows servers.
• Mandatory sodium extension. In many distributions, it comes as a separate package.
• max_input_vars greater than or equal to 5000. The PHP default is 1000. With it, large forms, like the gradebook page for a full class, save only partially without showing an error.

Full details on CPU, RAM, and scaling are in our guide to Moodle 5.x server requirements. Before anything else, open Site administration → Server → Environment check: Moodle itself will highlight in red what prevents the upgrade.

The /public Folder and the Router: A Change That Requires Web Server Configuration

Moodle 5.1 reorganized its files. Everything web-accessible moved into a `/public` subfolder, with sensitive files residing above it. Anyone upgrading Moodle 4.5 to 5 hasn't encountered this before, so this entire step will be part of your upgrade.

In practice, three things change:

1. The DocumentRoot changes. The web server (Apache or Nginx) must point to moodle/public, not just moodle. The official upgrade documentation is clear: without reconfiguring the server, the upgrade will not proceed.
2. The config.php file moves to the root. It returns to the main Moodle folder, not inside public.
3. Third-party plugins need to be moved. Those already installed remain in their old location, above /public. Each must be moved to the equivalent path within the new structure. The 5.1 release notes explicitly state this.

The Router Is No Longer Optional

Along with the public folder came the Moodle router. According to the documentation Configuring the Router, this configuration is mandatory starting with 5.1. In Apache, this means a FallbackResource /r.php within the <Directory> block. In Nginx, it's a try_files $uri /r.php;. Afterward, you inform Moodle with $CFG->routerconfigured = true; in config.php.

Forgetting the router won't bring down the entire site. It generates specific 404 pages and a 'router not configured' alert in the environment check. This type of defect often only appears days later when a professor tries to access a seldom-used screen.

What's Removed from the Core Between 4.5 and 5.3

This is an item that pedagogical coordination needs to review before IT. When you upgrade Moodle 4.5 to 5, you inherit all changes that have been removed from the core between versions 5.0 and 5.3, according to the official notes:

• Atto Editor (5.0): TinyMCE takes over. Old content remains; what changes is the editor the instructor uses.
• Chat and Survey activities (5.0): removed from the standard package. If any course uses them, decide what to do with the data beforehand.
• CAS authentication and all MNet plugins (5.0): if institutional login depends on CAS, this is a blocker. An alternative (SAML, OAuth 2) is needed before the upgrade date.
• MimeTeX filter (5.2): those using TeX formulas need to check their configured filter.
• Classic Theme (5.3): anyone still running Classic, or a child theme of it, needs to migrate to Boost or a compatible custom theme.

None of these items appear as errors during the upgrade. They show up as instructors complaining on Monday. That's why they're part of the inventory, not the go-live day.

Plugins: The Inventory That Determines Your Timeline

In almost every project I lead to upgrade Moodle 4.5 to 5, the timeline is dictated by the most delayed plugin, not by Moodle itself. The process that works:

1. List Everything That Isn't Core

In Site administration → Plugins → Plugins overview, filter for additional plugins. Export the list. For each, note: who maintains it, installed version, if it's in use, and which courses depend on it.

2. Classify into Three Groups

• Compatible: The Moodle plugins directory already declares support for 5.3. Download the new version.
• No sign of life: Last version is old, author unresponsive. This is the real risk. Either someone takes over maintenance, or the plugin is removed.
• Custom-built: Developed for the institution. Requires code review against deprecated APIs, which 5.2 marked as the final removal of old methods from versions 2.x, 3.x, and 4.x.

3. Remove What No One Uses

An installed but unused plugin is just an upgrade cost. Upgrading Moodle 4.5 to 5 is the best time to uninstall anything left over from old projects. Fewer plugins mean less attack surface and less testing time.

Checklist for a Smooth Moodle 4.5 to 5 Upgrade

This is the sequence I follow. It starts with a staging environment, a faithful copy of production where everything is tested beforehand.

Before (2 to 6 weeks)

1. Run the environment check pointing to 5.3.
2. Upgrade PHP to 8.3 and the new database (MariaDB 11.4 or PostgreSQL 17) in staging.
3. Clone production to staging: code, moodledata, and database.
4. Inventory plugins and resolve any blockers.
5. Test critical workflows with real instructors: quizzes, assignment submissions, gradebook, certificate issuance, automatic enrollment.
6. Measure the upgrade time in staging. This number defines your maintenance window.

On Upgrade Day

1. Notify students and instructors in advance, including the date and time of the downtime.
2. Activate maintenance mode. The upgrade script does not do this automatically.
3. Perform a full backup of the three items (see next section).
4. Replace the code, copy config.php to the root, move plugins into /public.
5. Adjust DocumentRoot and router in the web server.
6. Run the upgrade from the command line with php admin/cli/upgrade.php, the option recommended by documentation for large sites.
7. Purge caches, review the environment check, and test critical workflows before going live.

After (First Week)

After upgrading Moodle 4.5 to 5, monitor PHP error logs, scheduled tasks (cron), and response times. Large upgrades often rebuild indexes and caches, making the first day of real use heavier. If your LMS feels sluggish, our guide to diagnosing slow Moodle helps distinguish between an upgrade issue and an existing infrastructure problem.

Rollback: The Plan B That Must Exist Before You Start

Before upgrading Moodle 4.5 to 5, be aware: Moodle does not support downgrades. Once the upgrade writes the new version to the database, the old code refuses to run on it. Rolling back means restoring the entire previous state.

The official documentation lists the three backup items, and all must be from the same moment:

Item	What It Is	How I Do It
Code	The Moodle folder with plugins and config.php	Keep the old folder intact and upload the new one alongside it
moodledata	Uploaded files, caches, sessions	Copy with rsync while the site is in maintenance mode
Database	All tables	Full dump (or volume snapshot) after activating maintenance mode

Three rules that make rollback a reality, not just an intention:

• Test the restoration in staging. An untested backup is just a hypothesis. We have an entire article on this: Moodle backup and restoration routine.
• Define the rollback criteria beforehand. Example: if, within two hours after the upgrade, the quiz or gradebook doesn't work, roll back. This should be decided the day before, not at 11 PM with the director on the phone.
• Anything entered after the upgrade will be lost in a rollback. That's why student access is only granted after final testing.

When NOT to Upgrade Now

Upgrading Moodle 4.5 to 5 is mandatory by October 2027 for anyone wanting to continue receiving security patches. Doing it this week? No. Hold off on the upgrade when:

• It's exam week, grade submission, or the start of the semester. The right window is during periods of lowest usage, and that's found in the academic calendar, not the IT calendar.
• A critical plugin doesn't have a version for 5.3. Running the new Moodle without integration with your academic system is worse than waiting a few months.
• There's no staging environment. Upgrading directly in production, skipping three change cycles, is a gamble.
• You're thinking of going live on release day. 5.3.0 just came out. The official calendar predicts 5.3.1 for December 7, 2026. Staging now and going live after this first correction is the pace I recommend.

Waiting too long also comes at a cost. Those who delay until September 2027 will compete for the window with the semester itself and, days later, be without security patches.

How Agathas Web Solves This

Upgrading Moodle 4.5 to 5 is exactly the type of project described on our Moodle services page. Our team holds Moodle Developer Certification from the Moodle Academy and conducts migrations between versions, from the 3.x line up to 5.x, and between servers. We are an independent service company, not a Moodle Partner.

In practice, the process is this:

1. Free 1-hour diagnostic. We understand your current version, server, plugins, integrations, and academic calendar.
2. Technical proposal. A document outlining the target version, necessary infrastructure, plugin list and actions for each, timeline, and investment. Pricing considers database complexity and data volume, and the proposal is delivered within 5 business days.
3. Staging and execution. We set up the production copy, resolve plugins and themes, test with your team, and execute the cutover within the agreed window, with backup and rollback criteria defined beforehand.
4. Post-go-live monitoring. We closely monitor during the first few weeks.

Anyone who doesn't want to go through this every cycle can maintain their environment with a monthly SLA: security and version updates, 24/7 monitoring, verified backup, and WhatsApp support during business hours, starting from $800/month. Custom plugin code and data remain with the institution, ensuring no lock-in. If the server is the bottleneck, Moodle hosting comes with PHP, database, and cache already adjusted for the new version.

To schedule a diagnostic, use the form or WhatsApp on the Agathas Web Moodle services page.

Conclusion: Upgrading Moodle 4.5 to 5 Is a Project, Not a Command

The path in one sentence: go directly to 5.3 LTS, start with the database and PHP, treat the /public folder and router as part of the scope, inventory plugins before setting a date, and only go live with a tested rollback.

The real deadline is October 4, 2027, when 4.5 stops receiving security updates. For an institution with two semesters in between, that's less time than it seems. Those who start staging now can calmly go live during the break. Those who delay will upgrade Moodle 4.5 to 5 in a hurry, and haste is where upgrades go wrong.

If you want a realistic timeline for your environment, request a free diagnostic on our Moodle services page. You'll leave with a target version, a list of blockers, and a suggested window.