Moodle 5.0 end of support: upgrade, stay on 4.5 LTS or migrate?

Moodle 5.0 end of support arrives on October 5, 2026. After that date Moodle HQ stops releasing security fixes for 5.0.x, so every new vulnerability stays open on your site. If you run 5.0, upgrade to 5.2 now or to 5.3 LTS once it settles. If you never left 4.5 LTS, you're covered until October 4, 2027.

If the deadline makes you question Moodle itself, LMS Advisor imports your Moodle .mbz course backups and runs in our cloud or self-hosted on your own server, with SSO, certificates and proctored exams built in rather than added as plugins. Patch your current site either way while you decide.

Migrating to a different LMS is a legitimate third option, and so is handing the whole thing to a Moodle hosting partner. None of them is an excuse to sit on an unpatched site while you decide. Below are the dates, the real work behind each path, and a 30-day plan to reach a decision.

Which Moodle support dates matter this fall?

Moodle releases a new version every six months. Standard releases get 12 months of bug fixes, then 6 months of security-only fixes. Long-term support (LTS) releases get security fixes for 36 months. That is the pattern on the official Moodle releases and support calendar, and it's where every date below comes from.

Two things jump out. First, October 5 is a busy day: 5.0 loses security support, 5.1 loses bug fixes and moves to security-only (it's patched until April 19, 2027), and 5.3 LTS is scheduled to ship. Second, 5.2 and 4.5 LTS stop getting security fixes on the same day, October 4, 2027. So upgrading from 5.0 to 5.2 buys you exactly as much runway as staying on the old LTS would have. Either way, most sites end up on 5.3 during 2027.

What does Moodle 5.0 end of support mean for a live site?

Nothing switches off on October 6. What changes is that the next security fix won't include a 5.0.x release.

On September 22, 2026, Moodle published security advisory MSA-26-0042, a blind SQL injection risk rated "Serious". It was fixed in 5.2.3, 5.1.7, 5.0.10 and 4.5.14. The affected list also says "and earlier unsupported", which means older versions carry the same hole with no patch coming. After October 5, the next advisory like that will list 5.0 in that unsupported bucket. And because advisories are public, they double as a description of what's open on every site that hasn't upgraded.

A few other things go stale around the same time:

• Plugins. New releases of the plugins you depend on will increasingly target 5.2 and 5.3 only.
• PHP. 5.0 and 5.1 accept PHP 8.2 as their minimum, and a lot of those sites never moved past it. The PHP project's supported versions page shows 8.2 security support ending December 31, 2026. If that's what your server runs, the layer under Moodle is on a short clock too. (Both releases also support PHP 8.3 and 8.4.)
• Audits. Vulnerability scans and customer security questionnaires tend to flag an unsupported LMS version, and someone has to explain it.

Option 1: upgrade to Moodle 5.2 or 5.3

For most 5.0 and 5.1 sites this is the default answer. The work is real, but most of it happens outside Moodle.

Should a 5.0 site go to 5.2 now or wait for 5.3 LTS?

Our usual advice is 5.2 now, then 5.3 in the first half of 2027. 5.2 has been out since April and has several point releases behind it. 5.3.0 lands on the same day 5.0 loses support, and a .0 release on day one is not where you want a production site that trains or certifies people. Waiting for 5.3.1 or 5.3.2 means running unpatched for weeks or months in between. If your plugins aren't ready for 5.2 yet, 5.1 is a reasonable stopover: it's patched until April 19, 2027, still accepts PHP 8.2, and needs PostgreSQL 15 rather than 16. You still have to make the /public change.

Sites on 5.1 have until April 2027, so they can plan a move straight to 5.3 once it settles.

What breaks when you upgrade from 5.0?

• The web server document root. Moodle 5.1 introduced a /public directory. The Moodle 5.1 release notes say your web server's document root now needs to point at /public instead of the main Moodle folder, and that previously installed plugins have to be moved into the right place inside it by hand. This is the step that catches out hosts who upgrade by habit. On shared or managed hosting, you may need your host to change the document root for you.
• PHP and the database. The Moodle 5.2 requirements call for PHP 8.3 or later, PostgreSQL 16, MySQL 8.4, MariaDB 10.11 or SQL Server 2019. A 5.0 site can run on PostgreSQL 14, so a database upgrade may come first. That's often the longest lead-time item.
• Plugins and themes. Every third-party plugin needs a version marked compatible with your target release. Custom themes cause the most trouble.

The official Moodle 5.2 upgrade guide covers the mechanics: back up the code, the moodledata folder and the database separately, check the environment, put the site into maintenance mode, and test the whole thing on a copy of production first. Do the copy. We've seen plenty of upgrades that ran cleanly and then failed on the first SCORM launch or the first certificate issued.

Option 2: hold on 4.5 LTS if you never moved to 5.0

If you're still on 4.5, you made a sensible call. It's patched until October 4, 2027, and it supports PHP 8.3, which the PHP project secures through the end of 2027. This October, just keep applying 4.5.x point releases. One catch: 4.5 still installs on PHP 8.1, which the PHP project no longer supports at all. If your server is on 8.1, move it to 8.3 now.

The better news is the upgrade path. According to the Moodle 5.3 release notes, you can upgrade to 5.3 from 4.5 or later. That means a 4.5 site can go straight to 5.3 LTS and skip 5.0, 5.1 and 5.2 entirely, landing on a version supported until October 1, 2029. One upgrade cycle instead of three.

The trade-off is that you absorb three releases of change in one go. The Moodle 5.0 release notes list the removal of the Atto editor, the Chat and Survey activities, CAS authentication and all MNet plugins from core. Then comes the 5.1 /public change, then the 5.3 requirements (PHP 8.3, PostgreSQL 16 or MySQL 8.4). If you rely on Chat, Survey or CAS sign-in, sort out replacements before the upgrade.

Can a 5.0 site go back to 4.5? Not realistically. Moodle upgrades change the database schema one way, and there's no downgrade tool. The only route back is restoring a backup taken before the upgrade, and you'd lose everything that happened since.

Option 3: move to partner hosting or MoodleCloud

Many Moodle teams aren't short on Moodle knowledge. They're short on server time. If that's you, handing hosting and upgrades to someone else is often the right answer.

Moodle Certified Partners

Moodle's Certified Partner directory lists hosting, support, custom themes, integration and training services, and it showed 125 partners when we checked in September 2026. A partner-managed site keeps your plugins and customizations, and the partner handles the PHP, database and /public work. For a plugin-heavy site, this is usually the lowest-disruption way out of the upgrade treadmill. Before signing, ask:

• Which versions do you run, and how soon after release do you move customers to a new LTS?
• Are upgrades included in the contract, or quoted each time?
• Who tests our third-party plugins before an upgrade, and what happens if one isn't compatible?
• Where is our data hosted, and in what format do we get the database and moodledata if we leave?

MoodleCloud

MoodleCloud is Moodle HQ's own hosted service, and it's simple for a reason. Its MoodleCloud plans page states plainly that it doesn't allow plugins to be installed, and points you to Moodle LMS or Moodle Workplace through a certified partner if you need them. That makes MoodleCloud a good home for a small, fairly plain Moodle site and a poor fit for one built around a certificate plugin, a custom theme or a third-party SCORM or reporting add-on. Check your plugin list before you look at pricing.

Option 4: migrate to a different LMS

Staying on Moodle is a valid choice for plenty of organizations, especially ones with academic-style courses, Moodle skills in house and heavy use of activities like Workshop, Lesson or the Database activity. Other platforms don't have direct equivalents for some of those, and rebuilding them is where migration budgets go to die.

Migration starts to make sense when the upgrade conversation keeps exposing the same pattern: Moodle is running corporate training or certification, a large share of your admin time goes to keeping the server and plugins in step, and the features you actually use (courses, SCORM, quizzes, certificates, reports) are ones other platforms cover without add-ons. If you're weighing hosting as part of that, our guide to choosing between self-hosted and cloud LMS deployment covers the operational side.

Two warnings from rescue work. First, a migration takes months, and your current site needs security fixes throughout, so upgrade to a supported version even if you plan to leave. Second, most "Moodle alternatives" roundups skip the data question entirely. The TalentLMS list of Moodle alternatives (last updated June 11, 2026, when we checked it in September 2026) recommends seven platforms and warns that every plugin adds maintenance. It doesn't say what happens to your .mbz backups, gradebook history or plugin activities when you move. Those are the questions that decide how hard the move is.

What does a Moodle .mbz backup carry, and what does it leave behind?

A Moodle course backup is a single .mbz file. The MoodleDocs course backup page lists what you can choose to include: users (or anonymized users), role assignments, groups and groupings, user files, comments, user completion details, course logs and grade history, plus activities, blocks and filters. Backups made with no users end in -nu.mbz, and anonymized ones end in -an.mbz.

That's what goes into the file. What comes out depends on the system reading it. Here's how we plan it:

Courses with a lot of video produce very large .mbz files, and those often fail on upload during a restore. The course restore documentation sends you to the file upload size settings when that happens, and other platforms have their own limits. And if you need completion and certificate history for auditors, don't count on it traveling inside course backups. Export it as reports and keep them with your records. Our LMS migration checklist walks through keeping that history intact.

LMS Advisor, our platform, imports Moodle .mbz course backups but not Moodle logs, grade history or plugin activities, so we tell teams to archive those separately whichever platform they pick. The section after the 30-day plan shows what the move looks like.

A 30-day decision plan for Moodle admins

Days 1 to 7: take inventory

1. Confirm your exact version under Site administration > Notifications, and note the PHP and database versions from Site administration > Server > Environment.
2. List every additional plugin from the Plugins overview page. For each one, check the Moodle plugins directory for a release that supports 5.2 or 5.3.
3. Flag anything removed in 5.0: Chat, Survey, Atto-dependent content, CAS sign-in, MNet.
4. Write down who hosts the server and who can change PHP, the database and the document root.

Days 8 to 14: pick a path

1. On 5.0: plan 5.2 now. On 5.1: plan 5.3 in 2027. On 4.5: plan 5.3 before October 2027.
2. If server work is the bottleneck, get quotes from two or three hosting partners.
3. If the platform itself is the problem, shortlist alternatives and ask each one to import a real .mbz from your site.

Days 15 to 30: test and schedule

1. Clone production to a staging server and run the upgrade there.
2. Test the things people notice: login and SSO, a SCORM launch and resume, a quiz attempt, grade export, certificate issue, and the reports your managers actually open.
3. Book a maintenance window, tell learners, and take fresh backups of code, moodledata and the database the same day.
4. If you chose migration, run the upgrade anyway and put the migration on its own timeline.

How a move from Moodle to LMS Advisor works

We built LMS Advisor after years of fixing and migrating Moodle sites, so it reads the .mbz files you already have. If option 4 is on your shortlist, here is where each piece of a typical corporate Moodle site ends up.

The limits are real. There's no plugin directory, you can't change the source code, activities such as Workshop and the Database activity have no direct equivalent, and pricing is quote-based. Our LMS Advisor vs Moodle comparison lays out where Moodle's open-source freedom and plugin community win. If you'd like to see how your own course backups behave, request a demo and bring a .mbz file.

Frequently asked questions

When does Moodle 5.0 support end?

Moodle 5.0 security support ends on October 5, 2026. General support (bug fixes) already ended on April 20, 2026. After October 5, no new 5.0.x security releases are planned, so sites should move to 5.2, or to 5.3 once it has a point release or two.

Is Moodle 4.5 LTS still supported in 2027?

Yes, until October 4, 2027. Moodle 4.5 only gets security fixes now, since general support ended in October 2025. Sites on 4.5 can upgrade straight to 5.3 LTS, which is supported until October 1, 2029.

When does Moodle 5.1 support end?

Moodle 5.1 general support ends on October 5, 2026, and security support ends on April 19, 2027. That gives 5.1 sites about six months to plan an upgrade, most likely to 5.3.

Should I upgrade Moodle 5.0 to 5.1 or 5.2?

Go to 5.2 if your plugins support it. It's patched until October 4, 2027, while 5.1 only gets security fixes until April 19, 2027. Budget for PHP 8.3 and PostgreSQL 16 or SQL Server 2019, which 5.2 requires. 5.1 still accepts PHP 8.2 and PostgreSQL 15.

Can LMS Advisor import Moodle courses?

Yes. LMS Advisor imports Moodle .mbz course backups and runs the SCORM, xAPI and cmi5 packages you already own as lessons. Logs, grade history and third-party plugin activities don't come across, so export those as reports before you switch. You can run it in our cloud or self-host it on your own server.

Is it time to leave Moodle for another LMS?

Only if the platform itself is the problem, not just the server work. If your pain is upgrades and hosting, a Moodle Certified Partner can take that on. If you're running corporate training on Moodle and fighting plugins to get basic reporting and certificates, a migration may be worth pricing, but patch your current site first.