Why a Moodle 4.5 upgrade should start with the supported path
Start with the supported path. For a self-hosted Moodle 4.1 site that no longer receives support, the upgrade is a move to Moodle 4.5 LTS, and it should be planned as a controlled migration of live data, not a patch applied to the existing server. The site holds courses, grades, user records and plugins that cannot be lost, so the first decision is the target version and the order of steps, made before anyone changes production. Later choices, from the database version to plugin replacements, depend on that target. Setting the target first keeps the project tied to a release line that still receives fixes.
Moodle 4.5 is a long-term support release, first released on 7 October 2024. According to Moodle's releases page on moodledev.io, it receives security support until 4 October 2027. That date matters for two reasons. It sets how long the site can stay on this version while still receiving security fixes, which determines when the next upgrade must be planned. It also separates a planned LTS move from a site that keeps running on a version with no security cover. Confirm the general support end date for 4.5 on the same releases page and record it alongside the security date in your upgrade plan.
Two facts must be confirmed before any work is scheduled. The first is your starting point. This plan assumes a site on Moodle 4.1.2, so check the exact build your site runs and confirm in the Moodle 4.5 release notes whether that build is an accepted starting point or whether an intermediate update is needed first. The second is the 4.5 requirements: the minimum PHP version and extensions, the supported database versions, and any web server or directory layout changes. Do not carry requirements over from a later release, because each major version sets its own minimums. Record the answers in one requirements sheet that the project owner signs off.
Beyond the version numbers, the supported path depends on decisions that someone must own. Decide who approves the target version, who confirms that courses, grades and certificates survived the move, and what the rollback point is if the upgrade fails. Inventory every installed plugin and check whether each has a release for 4.5 or a documented replacement. A plugin without a 4.5 release can block the upgrade or leave a feature missing for learners. Ask each plugin's maintainer or your vendor to confirm compatibility in writing, and treat unclear answers as a reason to plan a replacement.
When you ask a partner for a quote, request the scope in writing before work starts. It should list the starting build check, the requirement review against the 4.5 release notes, the staging rehearsal, the plugin compatibility review, the cutover plan and the rollback test. Ask whether each item is included or priced separately, and who maintains the staging copy during testing. The schedule should follow these confirmations. Once the starting point and requirements are confirmed, the remaining steps can be sequenced against your change windows and your academic calendar.
Which 4.5 changes affect your site and what to do about each
This table lists the 4.5 LTS changes most likely to affect a site moving from 4.1 LTS, with the impact on users and administrators and the action to take. Read the exact PHP and database minimums from the Moodle 4.5 release notes before changing any server. Work through the rows in order, because the plugin and authentication checks depend on a confirmed server and database baseline.
| Change | Impact | Action needed |
|---|---|---|
| PHP and database requirements | Moving to 4.5 requires newer PHP and database versions than 4.1 LTS, and any server below the minimum blocks the upgrade. | Confirm the exact PHP and database minimums in the 4.5 release notes, then build a test server on that stack first. |
| AI subsystem and enabled providers | Changes to the AI subsystem affect which AI features are available and how each provider is configured and used. | Confirm the AI changes in the release notes, list every provider you enable, and disable any your data policy does not approve. |
| Open Badges 3.0 and existing badge issuers | Badges issued under earlier Open Badges versions may need checks for display, verification and sharing after the upgrade. | Inventory badge issuers, sample issued badges, and test display and verification on a staging copy before cutover. |
| TinyMCE editor and custom markup | Editor changes can alter how existing course text, embedded media and custom HTML render or save. | Export pages that use custom markup, compare rendering before and after the upgrade, and fix or restyle affected content. |
| Third-party plugin compatibility | Plugins built for 4.1 may lack a 4.5 version, and an incompatible plugin can stop the upgrade or break pages. | List every installed plugin, confirm a 4.5 version exists for each, and replace or remove any that lack one. |
| Authentication plugins such as SAML 2.0 | The auth_saml2 plugin's listed support range runs to Moodle 5.1 and does not state 4.5, so compatibility must be confirmed. | Confirm 4.5 support with the plugin maintainer, then test SSO login, user creation and field mapping on staging. |
Checking the supported upgrade path before changing code
Before anyone changes code, confirm that your current Moodle 4.1 LTS site can move to 4.5 LTS directly, or whether the 4.5 release notes require an intermediate step. Moodle sets a minimum starting version for each major upgrade, so the 4.5 requirement has to come from the 4.5 release notes, not from an assumption based on earlier hops. The facts that can be stated now are these: Moodle 5.1 requires sites to be on 4.2.3 or later, and Moodle 5.3 requires 4.4 or later. A site on 4.5 already meets both minimums, which means the 4.5 target keeps the later 5.x options open without a separate catch-up upgrade.
Record the exact 4.1.x point release that is running today. Read it from the release value in the Moodle code's version file and cross-check it on the Site administration notifications page, then note the database and PHP versions alongside it. Also record where the code came from, whether that is a Git tag, a downloaded package or a managed hosting image. Many upgrade problems start with a site that is one or two point releases behind what the team believes it is running, so this record is the baseline every later check depends on.
Plan any intermediate point release before the major upgrade is scheduled. Moodle ships minor point releases every two months, in February, April, June, August, October and December, and the security fixes in those releases are part of the reason to stay current. Move to the latest 4.1.x point release first, test that step in a staging copy, and then confirm in the 4.5 release notes whether a specific point release is required as a stepping stone. Do not skip any stage the release notes name, even if a direct jump appears to work in a test database.
Write the path down as a dated change record before the work starts. The record should list the starting release, each intermediate release, the target release, the PHP and database versions required at each step, and the owner who signed off each stage. Ask any implementation partner to confirm this path in writing as part of the agreed scope, and ask them to show where each required stop comes from in the release notes. The same record becomes the reference for plugin compatibility and cutover planning covered in the sections that follow.
What to prepare before the first upgrade run
Each card is a gate the site must pass before anyone runs the upgrade on a copy of production. The gates are connected: the backup proves you can return to 4.1, the inventory tells you which components can block the move, the staging copy tests the move itself, and the change window puts the people who depend on the site in agreement before work starts.
Verified backup and tested restore
Take a full backup of the database, the moodledata directory and the Moodle code, then restore it to a separate machine and confirm that the site loads, logins work and course files open. A backup file that has never been restored is not a rollback plan. The site owner and the database administrator should sign off on the restore test, and the record should show the time taken, since that is the figure you need for the change window.
Plugin, theme and integration inventory
List every installed plugin, theme, local customization and external integration with its current version, its source and its owner. Check each one against the Moodle 4.5 LTS compatibility information published by its maintainer, and flag anything without a 4.5 release. Core ships authentication plugins for LDAP, LTI, OAuth 2, Shibboleth and web services, so confirm which of these your site actually uses and record the maintainer of any third-party plugin, such as a SAML 2.0 plugin.
Staging copy of the production stack
Build a staging environment that matches production in web server, PHP version, database engine and version, cache, cron setup and connections to external services such as SSO, HR feeds and file storage. Restore a recent production backup into it, run the upgrade there, and keep a written record of every error and manual step. Compare the PHP and database versions in staging with the 4.5 requirements in the release notes before you start, and confirm the web server document root and cron schedule.
Change window agreed with stakeholders
Agree a maintenance window in writing with course owners, the people who run SSO, and the people who run HR feeds. Course owners should confirm which courses can be paused and which assessments or exams fall in the window. SSO and HR feed owners should confirm how they will test login and enrolment sync after the upgrade, and who can roll back their side if the upgrade fails. Record the agreed window, the rollback decision owner and the contact for each group.
The upgrade sequence and the checks at each stop
The sequence moves a Moodle 4.1 LTS site to 4.5 LTS through a rehearsed staging upgrade, with a rollback point before each stage and defined checks before users return. Production stays on 4.1 until staging passes every check and the site owner signs off.
Freeze content and confirm the starting point
The site owner announces a freeze on course, user, grade and plugin changes. The Moodle administrator records the exact release, which should be 4.1.2 or a later 4.1 patch, the PHP and database versions in use, and the installed plugins with their versions. Rollback point: a full backup of the code directory and database is verified by restoring it to a scratch server, and the current code release stays on disk. The step is done when the inventory is signed off by the owner and the restore test has passed.
Build a staging copy and upgrade the stack
The team restores the verified backup to a staging environment that matches production in web server, PHP, database and data directory. Before changing Moodle, the engineer confirms the PHP and database versions required by Moodle 4.5 in the Moodle 4.5 release notes, then upgrades PHP and the database in staging only. Rollback point: production remains on 4.1 with its backup, and staging can be reverted to the recorded PHP and database versions. Return to the previous stack if the 4.1 site will not start cleanly on the new PHP version.
Update or replace plugins without 4.5 support
The developer checks each installed plugin against its listed Moodle 4.5 support in the plugins directory and the plugin's own repository. Plugins without support are updated, replaced or removed, and custom local plugins and themes are run through the Moodle plugin checker in staging. Rollback point: a backup of the plugin directories and the staging database, taken before the first plugin change. Return to that point if a plugin breaks the install and no supported replacement exists. The step closes when every plugin shows a 4.5-compatible version or a documented replacement or removal with a named owner.
Run the core upgrade in staging
The engineer puts the site into maintenance mode, switches the code to the 4.5 release, and runs the upgrade from the command line so that errors are written to a log that can be read in full. Rollback point: a staging snapshot taken immediately before the run, with the 4.1 code kept on disk. The run is complete only when the upgrade script reports success and the database schema matches the new release. Return to the snapshot if the upgrade stops on a schema error, a failed plugin install or a data migration that cannot finish, then fix the cause before running again.
Check administration, scheduled tasks and cron
The administrator works through the admin notifications page until no message remains that the upgrade should have resolved. The team confirms that cron runs on its configured schedule, that scheduled tasks complete without errors in the task log, and that background jobs, including any AI-related tasks, finish normally. Rollback point: the staging snapshot from the core upgrade, with the production backup still held. Return to that point if cron cannot be made reliable or if tasks fail in a way that points to a plugin or data defect. The step is done when the task log is clean for a full cycle.
Test logins, course access, grades, badges and editor
Testers run scripted sessions for each authentication method in use, such as manual accounts, LDAP, SAML 2.0 through a plugin or OAuth 2, and confirm sign-in and sign-out for each. They open courses in each role, check that enrolments and activities load, and compare sample gradebook and badge views with values recorded before the upgrade. They also confirm the text editor and the AI subsystem settings and provider connections behave as configured. Rollback point: the staging snapshot from the core upgrade. Return to it if a login path fails, grades differ from the recorded values, or an AI or editor setting does not hold. The step closes when the test lead signs the defect list.
Cut over production with a verified rollback path
The team runs production in the window agreed with the site owner. It enters maintenance mode, takes a final backup of code and database, and repeats the steps that passed in staging. The 4.1 code stays on disk and the database backup is confirmed restorable before the upgrade starts. Conditions set in advance trigger a return to 4.1: a failed core upgrade, a login failure for any method, a grade mismatch in the sample, or cron failures not fixed within the agreed window. The step is complete when the site owner signs off the production checks.
How to test a Moodle upgrade and roll back if it fails
The test plan decides whether the upgrade is accepted, and the rollback plan decides what happens if it is not. Both should be written and rehearsed on a copy of production before the production window is booked. Run the rehearsal on a copy taken from production with the same plugins, theme, authentication settings and cron configuration, so that the results describe the site users will actually log into. Functional checks should follow real use: log in through every authentication method that is enabled in production, including manual accounts and any LDAP, SAML 2.0 (auth_saml2) or other plugin in use. Then check enrolments from each enrolment method, quiz attempts and question bank use, assignment submission and grading, grade export, badge issuing, file upload, and the TinyMCE editor in activities, forums and blocks.
Performance checks need production-like data, not an empty test site. Ask your team or your implementation partner to confirm that the copy includes comparable numbers of users, enrolments, courses, quiz attempts, grades and files in moodledata, because database migration time and post-upgrade page speed both depend on that volume. Record baseline page times for course view, quiz start, gradebook and the assignment grading screen on the current 4.1 site, then repeat the same measurements on the upgraded copy. Time the upgrade run itself during the rehearsal, since that duration sets the length of the maintenance window. Also confirm that scheduled tasks and cron complete normally after the upgrade, because a site that appears to work can still fail silently in background jobs.
The sign-off list belongs to the business, not to the technical team. Each function that depends on Moodle should name one accountable person who writes the pass criteria for their area before testing begins. A registrar might sign enrolments and grade export, an assessment lead might sign quizzes, assignments and grading, and a learning design lead might sign the editor and course content. Each item should state the test, the expected result and the evidence kept, such as a screenshot or an exported file. The technical team runs the checks, but the named owner decides whether each item passes. Collect the signed list before the cutoff time so that the go or no-go decision rests on recorded approval rather than on the impression of the last test session.
Treat rollback as a decision with a cutoff time, agreed in writing before the window opens. Before the cutoff, the go or no-go owners review the sign-off list and any open defects against triggers that were defined in advance, such as failed authentication for a major user group or broken grade export. After the cutoff, the team moves forward and fixes issues on the new release, because restoring the old state would discard data written after the upgrade. Confirm the cutoff with the business sponsor, the technical lead and the people who can authorize a restore, and make sure everyone knows who holds the decision if the lead is unavailable.
If rollback is chosen, restore the database and moodledata together from the same pre-upgrade backup point, then redeploy the 4.1 code and its matching configuration. The two must come from the same point because file records in the database must match the files on disk. Restoring only the code is a common mistake. The 4.5 upgrade changes database structure and stores the new version in the configuration, so the old 4.1 code will find tables, columns and version values it does not expect and may refuse to start or fail on specific pages. Rehearse this restore on the copy, including timing and the exact backup set, so that the rollback path has been proven before it is needed.
What makes a Moodle 4.5 upgrade longer or more expensive
This table lists the drivers that set the size of a Moodle 4.1 LTS to 4.5 LTS upgrade and shows how each one can be reduced before work starts. Planning, testing and remediation are one-time costs for this move, while patching and the next major upgrade recur. Plugin inventory and staging availability are the drivers most worth settling early.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Third-party plugins and themes | Each plugin needs a version for 4.5 or a replacement. Unmaintained plugins usually drive remediation. | Inventory every plugin and theme with its version and maintainer. Remove unused ones before the upgrade and confirm 4.5 support in each release note. |
| Custom code that touches core | Edits to core files or overrides can break on upgrade and need manual rework. Each one needs a test to prove it still works. | Move customizations into plugins or documented extension points where possible. Record every core change so it can be rechecked against 4.5. |
| Course content and files | Large course and file stores lengthen the database migration, file checks and backup window. Old content may use features that changed. | Clean up unused courses and files before the upgrade. Take a full backup and time a restore on staging so the window is known. |
| Integrations to retest | SSO, HR feeds, video, storage and plagiarism connections each need a login or data test on 4.5. Authentication changes affect every user. | List each integration with its owner and test cases. Confirm vendor support for Moodle 4.5 before scheduling retests. |
| Staging infrastructure | A production-like copy of code, database and data is needed to rehearse the upgrade. Without it, the first real run becomes the test. | Match staging to production's PHP, database and web server versions, then confirm what 4.5 requires. Refresh it from a recent backup before each rehearsal. |
| Users who must sign off | Each department or course owner who approves test results adds a review cycle. Late sign-off reopens fixes. | Name approvers and their test scope during planning. Agree acceptance criteria in writing so sign-off can close quickly. |
| Recurring releases and next upgrade | Moodle 4.5 security support ends 4 October 2027, so patching and another major upgrade will recur. | Budget minor releases and the next upgrade as a recurring cost. Decide whether support stays in-house or runs under a retainer. |
What a 4.5 site must address before moving to Moodle 5.x
The Moodle 4.5 upgrade is often the first step toward a later major release, so the requirements of the 5.x line should shape the 4.5 project from the start. Moodle 4.5 is an LTS release with security support until 4 October 2027. The next LTS, 5.3, was released on 5 October 2026 with general support until 4 October 2027 and security support until 1 October 2029. Upgrading to 5.3 requires a site to be running Moodle 4.4 or later, so a completed 4.5 upgrade meets that starting point. Plan the next hop as its own project with its own release notes review, and do not assume the 4.5 work covers it.
Several 5.x requirements become visible now. From Moodle 5.1, the web server document root must point to the new /public directory instead of the main Moodle folder. If it does not, the site may show directory listings or errors. Ask your infrastructure team to list every virtual host, reverse proxy, load balancer rule and container image that serves Moodle, including staging and disaster recovery copies. Confirm how each one sets its document root, and test the change on a copy of the 4.5 site before the production cutover.
The platform requirements also rise at each hop. Moodle 5.1 requires 64-bit PHP 8.2 or later, with PHP 8.3 and 8.4 supported, and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. Moodle 5.3 requires 64-bit PHP 8.3 or later, PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. If your 4.5 site runs PostgreSQL 15 or 16, the move to 5.3 includes a database upgrade with its own backup and rollback plan. Confirm the PHP version, database version and extensions your 4.5 site runs today, because those versions were not part of this section's facts and they set the size of the gap.
Moodle 5.3 removes the Classic theme from core. Any site still using Classic, or a custom theme built on it, needs a replacement theme chosen, configured and tested with course content before the target version is fixed. Also confirm the 5.0 removals that the sibling Moodle 5.0 page covers, such as the editors, activity modules, authentication methods and themes that leave core in that release. Check each one against your course content, plugins and integrations before you commit to a target. A removal that affects one course or one integration can change the schedule for the whole program.
Before you schedule the 5.x work, pick a candidate target and list what it requires: PHP and database versions, the document root change, theme decisions, and a compatibility check for every third-party plugin. Ask each plugin maintainer for the versions they support, and remove plugins that no longer have a supported release. Keep the 4.5 site on a tested, backed up state so that the next hop starts from a known position. A well-documented 4.5 handover makes the 5.x decision a planning exercise rather than an emergency.
Questions teams ask before upgrading Moodle 4.1 to 4.5
How much does a Moodle 4.1 to 4.5 upgrade cost?
The cost depends on the scope you agree in writing, and DeployOpen quotes follow from that scope. The main drivers are the number of installed plugins and how many of them need a version change, custom code or theme work, the number of environments (test, staging and production), the size of the database and file store, and how much testing your academic and administrative users need before sign-off. Some costs are one-time, such as the assessment, the upgrade itself and the cutover. Others recur, such as patching, plugin maintenance and later upgrades. Ask any provider, including us, for a quote that lists each deliverable, who performs it, which plugins are included, what testing is covered, and what happens if a plugin needs more work than expected.
How long does the upgrade take, and what sets the schedule?
The schedule is set less by the core upgrade than by plugin work, testing and approvals. Moodle 4.5 receives security support until 4 October 2027, so that date is a useful planning anchor, but your own calendar matters more. Schedule drivers include the number of plugins that need checking or replacing, how many test cycles your teachers and administrators can complete, whether a change freeze applies around exams or enrolment periods, and how quickly your team can approve test results. Ask for a written plan with milestones, an assessment phase, a staging rehearsal and a cutover window, and confirm which of these steps your provider counts in the fixed scope and which depend on your team.
What does our team need to provide before the upgrade starts?
Your team needs to provide four things before work begins. First, access: administrator access to the Moodle site, the web and database servers, the file store, and the environments where staging and testing will run. Second, plugin owners: a named person for each plugin or local customization who can confirm whether it is still needed and who knows its settings. Third, test users: teachers, students and administrators from each faculty or department who will run agreed test scripts on the staging site. Fourth, sign-off: a named decision-maker who accepts the test results and approves the cutover date. Put these responsibilities into the written scope, with owners and dates, so delays on your side are visible early.
Can our in-house Moodle team run this upgrade without a partner?
A capable internal team can run an upgrade like this, but only if it has done major Moodle upgrades before and can support the server stack. The work involves the command-line upgrade process, checks of PHP extensions and database versions, plugin compatibility checks, configuration and theme changes, and performance and backup verification. Teams with a small number of plugins, little custom code and time for a full staging rehearsal are often able to manage it internally. Teams with many plugins, custom themes, integrations with identity or HR systems, or a tight calendar usually need extra capacity. A practical test is whether your team can reproduce the upgrade on a copy of production and document each step before anyone touches the live site.
Can Moodle stay online during the upgrade?
Usually the site is taken offline only for the final cutover, not for the whole project. The assessment, plugin work and test runs happen on copies of the production site, so learners can keep using the live system while they proceed. The cutover normally requires putting the site into maintenance mode, taking a final backup, running the upgrade against the production database and file store, and then checking the result. The length of that window depends on database size, the number of plugins that run upgrade steps, and the server capacity you have. Ask for the planned outage window, the rollback plan if the cutover fails, and the time you will need to agree in advance with your academic calendar and support desk.
What happens if a plugin is not compatible with Moodle 4.5?
The plugin has to be resolved before cutover, and there are usually four options: find a version that supports Moodle 4.5, replace the plugin with a supported alternative, adapt the plugin through custom development, or remove it and change the process it supported. Check the plugin's listing in the Moodle plugins directory for stated supported versions, but also test it on staging, because a listing does not prove that every feature works. For example, the SAML2 single sign-on plugin lists support for Moodle 2.7 through 5.1 in the directory, so you would still need to confirm that the version you intend to use is supported for Moodle 4.5 and that your identity provider configuration works. Decide each case with the plugin owner, and record the decision in the scope.
Which Moodle 4.5 changes will users notice first after the upgrade?
The changes most likely to affect users are the ones that alter daily tasks: the AI subsystem settings and any AI features that administrators choose to enable, the behavior of Open Badges 3.0 for badge issuing and display, and changes to the TinyMCE editor that teachers use to write content and feedback. Each of these needs a test script that reflects how your staff actually work. Confirm the exact behavior, settings and any required configuration against the Moodle 4.5 release notes on moodledev.io before you write test cases, because the details matter for your training plan. Prepare a short guide for teachers and a support note for the help desk so the first week after cutover is not spent answering questions that a test run would have caught.
What PHP and database versions does Moodle 4.5 require?
Confirm the exact PHP and database versions in the Moodle 4.5 release notes on moodledev.io and in the Moodle requirements documentation before you plan the server work. Your provider should check these against your current PHP version, database engine and version, web server configuration and operating system, and state in writing which changes are included in the scope. Server changes often need separate planning because they affect other applications on the same hosts, and a PHP or database upgrade can have effects beyond Moodle. Also plan for the next step. Moodle 5.1 requires 64-bit PHP 8.2 or later and sites must be on Moodle 4.2.3 or later to upgrade to it, and Moodle 5.3 has its own higher requirements, so the server work you do now should fit the upgrade path you expect.
How DeployOpen scopes, delivers and supports a Moodle upgrade
DeployOpen plans the move from Moodle 4.1 LTS to 4.5 LTS as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. The work runs in infrastructure you control, from a rehearsal copy of your site through to a documented cutover.
How we scope
- The written scope names your current 4.1 LTS version, installed plugins, themes and custom code.
- Plugin compatibility checks against 4.5 LTS are listed as a deliverable, with each plugin marked upgrade, replace or remove.
- Ongoing support after cutover can be added as a retainer, quoted separately from the upgrade scope.
How we build
- Build a rehearsal environment from a copy of your production database and files.
- Run the upgrade in staging, record every step, and fix plugin and theme breaks before any production change.
- Test course content, quizzes, grades, enrolments and single sign-on, and check the AI subsystem and Open Badges 3.0 changes.
How we hand over
- A dated runbook records the server requirement changes, the PHP and database versions you must run, and the rollback steps.
- Plugin decisions, custom code changes and configuration changes are documented so your team can repeat or audit them.
- Your administrators and course editors receive a walkthrough of the interface changes users will notice after cutover.
How we support
- Confirm post-cutover support, monitoring and patch responsibilities in the written scope, before cutover is scheduled.
- Ongoing support, upgrades and continuous testing are available as retainers for infrastructure you control.
- Plan later upgrades around the 4.5 LTS security support window, which runs until 4 October 2027.
