Why a Moodle 4.5 to 5.3 upgrade needs its own plan
If you run a self-hosted Moodle 4.5 site, moving to Moodle 5.3 is a platform change, not a patch. Moodle 4.5 is a long-term support release from 7 October 2024, with security support until 4 October 2027. Moodle 5.3, released on 5 October 2026, is the next LTS release, with general support until 4 October 2027 and security support until 1 October 2029. Your 4.5 site is still supported, so the move is a planned decision about timing and risk, not an emergency. The question to settle first is which window you will use, and who owns the work inside it.
Several changes make this harder than it looks. Moodle 5.3 requires 64-bit PHP 8.3 or later, with 8.4 supported, so a site on an older PHP runtime cannot simply swap the core files. The database floors also move: PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Check the version of every database server that holds your Moodle data, including staging and reporting copies, and confirm that your hosting provider or internal platform team can supply them. Each of these changes can force an operating system or middleware upgrade that sits outside Moodle itself.
Two changes affect how the site is built and presented. Since Moodle 5.1, the web server document root must point to the new /public directory rather than the main Moodle folder. If it does not, users may see directory listings or errors, so the reverse proxy, virtual host and any load balancer configuration need to be reviewed before cutover. Moodle 5.3 also removes the Classic theme from core. If your institution uses Classic, or a child theme built on it, the theme must be rebuilt or adapted, and that work is usually the largest unknown in the plan.
The gate for this upgrade is that the site must already run Moodle 4.4 or later. A site on 4.5 meets that requirement, so you can start planning the 5.3 move now. Note that the 4.5 site must still be on a supported 4.5 point release before you begin. Confirm your current version in the site administration pages and check the release notes for each intermediate step. The rest of this page covers the work that remains: plugin and theme compatibility, the staged test and rollback plan, and the cutover itself.
Which parts of the stack change in this upgrade
Moving from 4.5 to 5.3 changes the server runtime, the database engine, the web root and the content of the site itself. Each card below names one component, what the 5.3 requirements change for it, and what your team should check before a test upgrade. Removals beyond those named here must be confirmed in the 5.3 release notes and against your own plugin list.
PHP runtime version
Moodle 5.3 requires 64-bit PHP 8.3 or later, and PHP 8.4 is supported. A site running PHP 8.2 or earlier needs a runtime upgrade before the code upgrade can run. Check the version the web server actually loads on every web node, plus any command-line host that runs cron. Confirm that PHP extensions and php.ini settings in the test environment match production.
Database server engine
Moodle 5.3 supports PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Many sites run older database servers, so the upgrade may also require a database engine upgrade alongside the Moodle code. Take a full database backup before any change. Test the upgrade against a restored copy that runs the same engine and version as production.
Web root and core codebase
From Moodle 5.1 onward, the web server document root must point to the public directory inside the Moodle code. Without that change, the site can show directory listings or errors. Review every virtual host, reverse proxy and container definition. Confirm that the core code is replaced in full from the 5.3 package, so no files from 4.5 remain in place.
Active theme and child themes
Moodle 5.3 removes the Classic theme from core. Any site, sub-site or course category that uses Classic, or a child theme built on it, must move to a supported theme during the upgrade. List which theme each site and sub-site uses today. Check custom theme templates and styles in a test course, because a theme that loads without errors can still display incorrectly.
Contributed plugins and AI providers
Each contributed plugin needs a version built for Moodle 5.3. Plugins without a 5.3 version can block the upgrade or break pages after it. Decide early whether each unmaintained plugin will be replaced, rebuilt or removed. Moodle 5.3 adds Anthropic's Claude as an AI provider plugin. If AI providers are enabled, review which providers are configured, what data they receive and who controls the credentials.
Cron and scheduled task runner
Scheduled tasks drive reminders, enrolment syncs, report generation and other background work. Confirm that cron runs under the upgraded PHP version and the correct system user on every node. Check that the cron job points to the updated code location. The supplied release facts do not describe cron changes for 5.3, so confirm them in the release notes and review task logs after the test run.
Decisions to make before the upgrade window
This table compares the five decisions that shape the 4.5 to 5.3 upgrade and the operational cost of each option. Read each row as a fork: pick the option that fits your constraints, then confirm the cost with your own administrators and hosting team before the window is booked. The main takeaway is that the PHP, database and theme choices carry more effort than the Moodle code change itself.
| Decision | Option | When it fits | Operational cost |
|---|---|---|---|
| Server approach | Upgrade in place on the existing server | Small site, spare maintenance window, and a tested full backup with a restore path | Lowest build effort, but rollback means restoring files and database together and the site is down while both change |
| Server approach | Build a new server and migrate the database | Old OS, PHP or database host is out of date, or you need a clean rollback target | Extra server cost for the parallel period, plus a database copy, cutover and DNS or load balancer change |
| Runtime timing | Move PHP and the database in the same window | Requirements force both changes anyway, and you can test the full stack once | Larger single change to test and roll back, but one downtime period and one test cycle |
| Runtime timing | Move PHP and the database separately, before Moodle | Current PHP or database is close to end of support, or hosting team needs a separate change record | Two outages or two test cycles, but each failure is easier to isolate |
| Theme | Keep Classic through a custom or child theme | Brand or accessibility sign-off depends on the current look and the team can maintain theme code | Ongoing theme code to rebuild and retest on each release, since Classic left core in 5.3 |
| Theme | Switch to a supported theme before upgrading | Theme code is thin or the team cannot maintain it | Theme configuration and user communication before go-live, with a visual review of course pages and reports |
| AI providers | Disable AI provider settings at go-live | Privacy review and teacher guidance are not finished, or data processing terms are unresolved | Near-zero configuration now, plus a later change request to enable each placement after review |
| AI providers | Enable AI providers after review | Data flows, usage limits and costs are approved for each placement | Review time, provider accounts and usage charges that recur once enabled |
| Target release | Accept 5.3 LTS as the target | You want general support to October 2027 and security support to October 2029, with an LTS base | One larger jump from 4.5 that needs PHP 8.3 or later and PostgreSQL 17 or matching database versions |
| Target release | Stay on 4.5 until its security date | Your upgrade window cannot absorb 5.3 changes this cycle | Continued security patching of 4.5 until its supported end, followed by a second upgrade to a later release |
How the upgrade sequence runs from inventory to cutover
The sequence moves a Moodle 4.5 site to 5.3 through a staged copy, with each step closed by a named check so the production window only has to repeat work that has already been proven in staging.
Inventory current runtime and extension versions
The administrator and DeployOpen's engineer record the current PHP version, database engine and version, web server, every installed plugin and the active theme, using the server's PHP output, the database client and the Moodle plugins overview page. The step closes when the inventory is signed off as a single list with a version or source for every item. Anything without a known version becomes a blocking item for the later steps.
Confirm plugin and theme support for 5.3
For each plugin and theme in the inventory, the team confirms with the vendor or maintainer that a release supports Moodle 5.3, and records the version to install. Items with no 5.3 release, or with a maintainer who has not confirmed, are flagged for replacement, removal or a decision by the client. The step closes when every item has a status of supported, replaced or removed, with the owner of each decision named.
Build a staging copy from production
The team restores a recent copy of the production database and the moodledata directory into a staging environment that matches production's network access, storage layout and web server configuration as closely as practical. Production credentials for outbound integrations such as SSO, HR feeds and email are disabled or pointed at test endpoints. The step closes when staging logs in as an administrator and shows the same course count and user count as production at the time of the copy.
Upgrade PHP and the database in staging
The engineer moves staging to 64-bit PHP 8.3 or later, and to a database version that Moodle 5.3 supports: PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. The step closes when the PHP version output and the database server version match the 5.3 requirements, and Moodle's environment check shows no failing items for the current code. Any extension that fails the environment check is resolved before moving on.
Point the web server to the public directory
The web server document root is changed to the /public directory that Moodle 5.1 introduced, and the old root is no longer served. The engineer then requests a directory path and a sample of static files to confirm that directory listings are off and that the site loads without errors. The step closes when those requests return the expected responses and the site renders its login page with no warnings in the web server error log.
Run the upgrade and review the logs
The Moodle upgrade is run in staging from the administration notifications, and the full upgrade log is captured. The administrator reviews every notification on the admin page and every plugin upgrade step in the log. The step closes when the upgrade log finishes without errors, the notifications page shows no unresolved items, and the site reports version 5.3 in the administration pages.
Replace or remove the Classic theme
Moodle 5.3 removes the Classic theme from core, so the site's theme is switched to a supported theme or to a child theme built for the client's brand. The replacement is tested on the main course, activity and admin pages, and on mobile layouts. The step closes when the replacement theme renders every page type in the test script without missing styles or broken navigation, and the Classic theme is confirmed gone from the installed list.
Run the full test script set
The team runs the agreed test scripts against staging, covering authentication for each login method, course creation, enrolment, grading, quizzes, file upload and each integration that feeds the site. Results are recorded against each script, and defects are logged with a severity and an owner. The step closes when every high-severity defect is fixed and retested, and a successful login is recorded for each role: student, teacher, manager and administrator.
Rehearse rollback from a verified backup
The team takes a full backup of production, restores it into a separate environment, and checks that it opens on the pre-upgrade stack. The rollback steps for PHP, the database, the web server root and the code are then written down and timed on the rehearsal. The step closes when the restored backup logs in on the 4.5 stack and the written rollback runbook has been run end to end once.
Schedule the window and freeze changes
The client agrees a production window with its users and stakeholders, and the change freeze covers code, plugins, themes and configuration from the final backup until cutover. A go or no-go review uses the staging results, the test log and the rollback rehearsal as evidence. The step closes when the window is confirmed in writing, the freeze is announced, and the named approver has signed the go decision. Lengths of the window and the freeze are set by the client's own change process.
What drives the effort and cost of the upgrade
This table lists the factors that change how much work a Moodle 4.5 to 5.3 upgrade takes, why each one matters, and how to reduce it before work starts. Read it as a checklist for scoping: the drivers marked as one-time affect this jump only, while the ones that recur will shape every later LTS move. Ask for each driver to be counted in the written scope before agreeing a quote.
| Driver | Why it changes the work | How to keep it down |
|---|---|---|
| Contributed plugins: number and maintenance state | Each plugin must have a 5.3-compatible release or be replaced, removed or rewritten. Abandoned plugins often block the upgrade entirely. | Inventory every plugin and its version, check the plugin directory for 5.3 support, and retire unused plugins before testing starts. |
| Custom code and local plugins | Code that calls core APIs changed between 4.5 and 5.3 must be reviewed and adjusted, which is the least predictable part of the work. | Use documented core APIs, keep local plugins in version control, and run a deprecation scan against the target release early. |
| PHP and database server versions | Moodle 5.3 requires PHP 8.3 or later and specific database versions. If the server runs an older PHP or database, that upgrade becomes a separate workstream with its own testing. | Confirm current PHP and database versions against the 5.3 release notes now, and schedule server upgrades before the Moodle code change. |
| Web server document root | From 5.1 onward the web server must point to the /public directory. Sites that still serve the main folder show listings or errors, and web server and proxy configs need changing alongside the code. | Document the current virtual host and load balancer settings, then rehearse the change on the test environment. |
| Themes and custom CSS | The Classic theme has been removed from core, so sites using it must move to another theme. Heavy custom SCSS and template overrides need rework and visual checks on every page type. | List every theme in use, count template overrides and SCSS files, and limit brand changes to a child theme where possible. |
| Database and moodledata size | Copy, backup and restore time grows with data volume, and moodledata holds files that must be copied along with the database. Large sites need longer staging copies and a longer rollback window. | Clean up old logs and temporary files according to the institution's retention policy, and measure both sizes before scheduling the cutover. |
| Integrations to retest | SSO, HR and student information feeds, grade returns, LTI tools and web services each need a test pass after upgrade. Failures often appear only in data flows, not on the login page. | Keep a list of each integration with its owner and a test script for the main success path, and agree which owners sign off. |
| Number of environments | Staging, test and production each need a matching copy of code, data and configuration. Fewer environments increase the risk at cutover, and more increase hosting and administrator time. | Agree the environments and their refresh schedule in the scope, and document how each one differs from production. |
| Compliance evidence to retain | The institution must keep records of the test plan, results, approvals, backup verification and the rollback procedure. Auditors and internal reviewers will ask for these records, and DeployOpen prepares them but does not certify the outcome. | Ask for a defined evidence list in the quote, store test results with the change record, and confirm retention periods with your compliance team. |
| Recurring drivers at each later LTS | Plugin compatibility, PHP and database minimums, theme changes and integration tests return with every LTS move, so a well-kept inventory and a repeatable test suite lower the cost of each later upgrade. | Keep the plugin inventory, integration tests and environment runbook current after go-live, and budget administrator time for each release cycle. |
How the upgrade differs for single-node and clustered Moodle
On a single server, the web server, PHP, Moodle code and moodledata all sit on one host, so the upgrade is one ordered sequence. The main risk is switching the code before the web server, PHP and database are ready for it. Moodle 5.3 requires 64-bit PHP 8.3 or later, with 8.4 supported, so the PHP change must be complete before the code is switched.
- Document root: Point the virtual host at the /public directory in the 5.3 code tree, check the configuration, and reload only after the test passes.
- PHP: Install PHP 8.3 or 8.4 alongside the current version, update the pool or module the site uses, and confirm that the CLI version used by cron matches.
- moodledata and caches: Confirm ownership, permissions and free space on moodledata after the code change, then check cache and file store settings in the administration pages.
- Cron and ad hoc tasks: Disable the cron entry for the window, then re-enable it after the upgrade and confirm that queued ad hoc tasks are processed.
Before you close the window, check that the site loads from /public, that cron runs under the new PHP binary, and that the database version meets the 5.3 requirement for your engine.
Behind a load balancer, every web node must run the same code, PHP version and configuration. The critical rule is that no node should serve 4.5 code against a 5.3 database, so all nodes change within one planned window. Shared moodledata, shared caches and shared sessions become the points where nodes depend on each other.
- Document root: Set the same /public path on every node and remove any node-specific paths from configuration so the nodes stay identical.
- PHP across all nodes: Remove nodes from the load balancer in turn, upgrade PHP on each, verify the version, and return it to service only after it passes a test.
- Shared moodledata: Confirm that every node mounts the same moodledata path with the same permissions before the change, and check it again after the code switch.
- Caches and sessions: Confirm that shared cache stores and session storage are reachable from every node, since one node with an unreachable store can produce intermittent errors.
- Cron and ad hoc workers: Run cron from one designated node or a dedicated scheduler, stop it during the window, and restart workers only after every node runs the new code.
After the window, confirm that all nodes report the same Moodle and PHP versions, and test a login and a background task through the load balancer, not only through a direct node address.
In containers, the code, PHP and web server are built into an image, so the upgrade becomes a new image rollout. The persistent parts, including moodledata, the database, caches and sessions, live outside the pods and must be planned separately. Most of the work happens in the image build and in the orchestrator's rollout settings.
- Document root: Build the image so the web server serves /public, and confirm that the ingress or service routes to the container port that serves it.
- PHP: Set the PHP version in the base image, rebuild, and confirm that every replica runs the same image digest.
- moodledata and caches: Mount moodledata on shared persistent storage used by all replicas, and keep cache and session services outside the pods.
- Cron and ad hoc tasks: Run cron as a scheduled job or a dedicated worker deployment, pause it during rollout, and restart it on the new image once the web pods are healthy.
- Rollout strategy: Plan the rollout so old and new pods do not write to the database in a way the other version cannot read, and keep the previous image available for rollback.
After rollout, check the running image digest in every pod, confirm that each volume is mounted, and verify that the worker deployments started on the new image. Confirm the rollout and rollback steps against your orchestrator's vendor documentation.
On networks with no outbound access, the upgrade must run entirely from packages and dependencies staged inside the boundary. That includes the Moodle code, PHP packages and extensions, operating system packages, database client libraries and any plugins or themes you keep. Anything missing on the day of the window becomes an unplanned outage, because the installer cannot fetch it.
- Staged packages: Copy the Moodle 5.3 code, PHP 8.3 or 8.4 packages and required extensions into the isolated network before the window, and verify checksums on import.
- Dependencies: Mirror any language package repositories the build needs, so that the installation does not depend on public repositories during the window.
- Database: Stage the PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 packages your database engine requires, and test them in a staging copy.
- Plugins and themes: Vendor every plugin and theme you keep and check each one for 5.3 compatibility before it enters the network.
- Container images: Mirror base images into the network and rebuild them there, so that no image pull is needed during the window.
The exact offline procedure depends on your build, so ask your platform vendor to confirm each step for your operating system, PHP packaging and database engine. Rehearse the full sequence on a staging copy before the production window.
What to monitor, back up and document after the cutover
The first weeks after a Moodle 4.5 to 5.3 cutover decide whether the upgrade holds, so the operations team should treat monitoring as a scheduled duty rather than an ad hoc response. Start with the web server error log, because the most likely fault after this jump is a document root that still points at the main Moodle folder instead of /public, which the 5.1 release notes say can produce directory listings or errors. Confirm the virtual host or server block was changed on every web node, then watch the error log for path and permission messages for at least the first business week. Check that cron, and any ad hoc task workers, run on schedule and that scheduled task status in the site administration pages shows no repeated failures.
Authentication needs its own watch list. Track failed logins by authentication method, since a change in PHP or plugin versions can break an external database, LDAP, OAuth 2 or SAML2 connection while manual accounts still work. If you use the SAML2 Single sign on plugin (auth_saml2), confirm that the version you deployed lists support for Moodle 5.3 in its plugin directory entry before go-live, and check the SSO error messages against the identity provider logs. Also confirm that the security support date for 5.3 (security support until 1 October 2029, per the Moodle releases page) and the general support end date are entered on your maintenance calendar, along with the dates of the minor releases that follow each six-monthly cycle.
Backups must be verified, not just taken. Before the upgrade, capture a full database dump and a complete copy of moodledata, and record the checksum of each. Restore that backup to a separate host running the old stack, and confirm that the site loads, that a sample of courses and user files opens, and that cron runs without errors. Keep the pre-upgrade backup until the rollback window you agreed closes, and do not overwrite it with later snapshots. The database and moodledata copies must be taken from the same point in time, or the restored site will reference files that do not exist.
The change record is what lets an auditor, a future administrator or your own support partner reconstruct the upgrade. Keep the versions before and after (Moodle core, PHP, database server and web server), a list of plugin versions with their sources, and the full upgrade log from the command-line upgrade run. Record the result of the rollback test, including the restore duration you measured, the steps taken and any data gaps. Finally, keep a decision log that states who approved the removal of the Classic theme and any unsupported plugins, what alternatives were considered, and which open issues were accepted. Store these records with the backups in a location your change control process controls.
Ask your partner or internal team to confirm, in writing, who owns each of these tasks after go-live, how long the monitoring period runs, and what counts as a rollback trigger. Those answers belong in the handover, because the first weeks after cutover are when a missed document root change or an expired backup window causes the most avoidable trouble.
Security checks specific to this upgrade
The jump from Moodle 4.5 to 5.3 changes the web root, the PHP and database baseline, and the plugin set, and each change can open an exposure if it is not verified. The cards below cover the items that move with this upgrade and what your team should confirm before cutover and after the restore test.
Web server serves only the public directory
From Moodle 5.1, the web server document root must point to the new /public directory instead of the main Moodle folder. Confirm that the web server configuration serves only that directory and that the rest of the Moodle code, including config.php, lib and any backup scripts, cannot be requested directly by a browser. If the document root is wrong, the site may show directory listings or errors, so test both the upgraded site and a request for a known internal file path.
PHP and database patch levels
Moodle 5.3 requires 64-bit PHP 8.3 or later, with PHP 8.4 supported, and PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Your current PHP and database versions may be out of support after the change, so confirm the vendor support and security patch status for the exact versions you will run. Record the versions in the change record and check them again after any operating system update during the window.
Administrator accounts and MFA settings
After the upgrade, review every account with site administrator rights, remove accounts that are no longer needed, and confirm that the MFA method your organization requires is still enforced for administrators and for any role with elevated capabilities. Check that the authentication methods enabled on the site match the approved list, since a restored or migrated database can carry over settings from the old environment. Keep a dated record of the review as evidence.
Third-party plugin code re-vetting
Plugins written for 4.5 may use APIs that changed or were removed in 5.3, and an outdated plugin can carry unpatched vulnerabilities. For each third-party plugin, confirm that a version is published for 5.3, review its source and maintainer activity, and check whether it has declared dependencies that need their own review. Disable or remove any plugin without a 5.3 release rather than running it unreviewed. Also review themes separately, since the Classic theme is removed from core in 5.3.
Upload and backup files outside web paths
During the upgrade window, copies of the database, moodledata backups, and uploaded course files may exist as archives or working copies. Confirm that none of these sit in a directory the web server serves, including the public directory and any temporary folders used by the restore test. Restrict file permissions on backup storage and remove staging copies once the test is signed off. Check that the moodledata directory is not reachable by URL.
Rotated secrets after the restore test
A restore test copies production data and often configuration into a second environment, so database passwords, SSO client secrets and any AI provider API keys may now exist in more places than before. Rotate the database credentials and SSO secrets for the production cutover, and confirm that the test environment holds no live credentials or uses rotated ones. If you enable an AI provider such as the Claude provider added in 5.3, store its key in your secrets manager and confirm who can read it.
How to test the 5.3 site and fail back safely
The test plan has to answer one question before the change window opens: can the team return the site to Moodle 4.5 quickly and prove it is serving 4.5 again. Testing 5.3 is only half of that. The other half is a rollback that has been rehearsed on a copy of production, with the backup restored into a scratch environment and the previous document root reinstated. Confirm with your own administrators who will run each step, in what order, and who has authority to call the rollback.
Run the functional smoke test in a fixed order on a staging copy built from a recent production backup. Start with login, testing each authentication method your site actually uses, such as manual accounts, email self-registration, LDAP, OAuth 2, or the SAML2 plugin if you have it installed. Next, check course access for each role: a student, a non-editing teacher, an editing teacher, a manager and a site administrator. Then check grade and completion views against known values, since a grade that displays incorrectly is harder to spot than a page that fails outright. Finish with file upload and download, including large files and files inside activities.
Cron-driven work needs its own checks because it rarely fails in front of a user. Confirm that scheduled tasks run to completion on 5.3, including notifications and backups, and that the ad hoc task queue drains. Check the scheduled backup output and confirm it is restorable. For each integration in use, such as an identity provider, an HR or student information system feed, or an external reporting tool, send a test transaction and compare the result with the 4.5 baseline. Record which tests passed on 4.5 before the upgrade so the comparison is against a documented baseline.
The rollback sequence should be written down as numbered steps: place the site in maintenance mode, restore the database from the pre-upgrade backup, restore the code from the pre-upgrade copy, return the web server document root to its previous setting, clear caches, and confirm the site serves Moodle 4.5 by checking the version under site administration and by running the smoke test again. Because 5.1 and later expect the document root to point to /public, the rollback must reverse that change as well, or the site may show directory listings or errors. Confirm the timing with your own team on the staging copy, since this document does not give durations.
Agree go or no-go criteria before the window, and write them down with a named decision owner. A reasonable set includes: every smoke test in the plan passes, no scheduled task fails in the first full cycle, grades and completions match the baseline, and no integration is in an unknown state. Any failed test should be logged with the date, environment, test step, expected result, actual result, screenshot or log extract, and whether it blocks go-live. A failure that blocks go-live triggers the rollback decision, not a debate in the window. Keep the failed-test log with the change record so the team can see what was tested and why the site stayed on 4.5.
Questions buyers ask before upgrading Moodle 4.5 to 5.3
Can a Moodle 4.5 site upgrade in place to Moodle 5.3?
Yes, a site on Moodle 4.5 meets the upgrade gate, because Moodle 5.3 requires a site to run Moodle 4.4 or later. In-place still means checking the stack first. Moodle 5.3 requires 64-bit PHP 8.3 or later (8.4 is supported) and one of these databases: PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later. Your web server document root must also point to the /public directory, a change introduced in Moodle 5.1. Plan for the Classic theme's removal from core in 5.3, and confirm that every installed plugin has a version compatible with 5.3 before you start.
What drives the cost of a Moodle 4.5 to 5.3 upgrade?
The main drivers are the number of installed plugins and how many of them need changes or replacement, the size and complexity of the environment, any custom code or theme work, and the amount of testing your courses and integrations require. Upgrade work is largely one-time, while hosting, plugin maintenance and later Moodle upgrades recur. Ask the provider to show the effort for each phase separately, so you can see where time goes. A quote should also state which party is paid for each task, and what your team must supply in time and access for the work to finish on schedule.
How should a fixed-scope Moodle upgrade quote be structured?
A fixed-scope quote should separate five parts: inventory, plugin work, environment work, testing and cutover. Inventory covers the plugin list, custom code, themes, integrations and data volumes. Plugin work covers upgrades, replacements and removals. Environment work covers PHP, database, web server and document root changes. Testing covers staging runs, course and grade checks, and integration checks. Cutover covers the production switch, backup point, rollback steps and post-cutover monitoring. Each line should name the deliverable, the acceptance check and the dependencies on your team, so the scope can be tested against the written plan.
What does the institution need to provide for a Moodle upgrade?
The institution needs to provide a named owner who can make decisions and sign off on test results. It also needs a complete plugin list with versions, and access to staging and production servers, including the database and the moodledata directory. Backup access is essential, so your team can confirm restore points before any change. Finally, you need a test group of staff and instructors who can check courses, quizzes, grades and integrations in staging. Confirm these items in writing before work starts, since missing access or unavailable testers are common causes of delay.
Can our own team upgrade Moodle 4.5 to 5.3 without a partner?
Yes, an experienced in-house team can do the upgrade if it has skills in PHP, databases and web server administration, and enough time to run and repeat staging tests. The work is less about the single upgrade command than about the checks around it: plugin compatibility, theme changes, the document root move, database version changes and rollback planning. Teams often underestimate the number of test cycles needed. Before deciding, count the people with those skills, the hours they can give to testing and the number of plugins that need attention.
How long does a Moodle 4.5 to 5.3 upgrade take?
Duration depends mainly on the plugin count, the size of the environment, the amount of custom code and the number of test cycles needed. No standard timeline applies to every site, so treat any single figure with caution. Ask the provider to state the expected duration, the phases it covers and the assumptions behind it, and make sure those items appear in the written scope. The scope should also name what would extend the schedule, such as late plugin releases or delayed access to staging, so both sides know which changes need a new agreement.
What support does Moodle 5.3 receive after the upgrade?
Moodle 5.3 is the next LTS release, with general support until 4 October 2027 and security support until 1 October 2029. Moodle 4.5, the current site, has security support until 4 October 2027. Confirm the current status on the Moodle releases page before you commit, because support windows are set by Moodle HQ. After go-live, your team or a partner will need to handle plugin updates, security releases and minor point releases. DeployOpen offers ongoing support and upgrades as retainers, and its work prepares systems and evidence but does not issue audit reports or certifications.
How DeployOpen scopes, upgrades and hands over Moodle
DeployOpen treats the move from Moodle 4.5 to the 5.3 LTS as a planned platform change, not a version bump. We start with your current PHP, database, web server and plugin inventory, then agree a written scope before any work starts. The upgrade runs through staged test copies with a rollback path, and the handover covers the documentation your administrators need to run the new version.
How we scope
- Inventory your PHP, database, web server and Moodle version, and confirm each against the 5.3 requirements in the release notes.
- List every installed plugin and theme, flag those without a 5.3-compatible release, and agree how each is kept, replaced or removed.
- Confirm the web server document root will move to the /public directory introduced in 5.1, and include that change in the written scope.
How we build
- Build a staging copy of your production site on the target PHP and database versions, then run the 4.5 to 5.3 upgrade path there first.
- Test core workflows such as enrolment, grading, backups and the Classic theme replacement, and record each result against the agreed test list.
- Take and verify a full backup of code, moodledata and database before the production cutover, and rehearse the rollback steps on staging.
How we hand over
- Deliver a written runbook covering the upgrade steps, configuration changes, document root setting and rollback procedure used.
- Provide a plugin register showing each component's version, source and compatibility status on Moodle 5.3.
- Walk your administrators through post-upgrade checks, cron and task monitoring, and where to find the release notes for future point releases.
How we support
- Engagements are fixed-scope, so the written scope defines what is included and what is handled as a separate change.
- Ongoing support, upgrades and continuous testing are available as a retainer if you want DeployOpen to handle future Moodle releases.
- Confirm with DeployOpen how security support windows for 5.3 (through 1 October 2029, per Moodle's releases page) fit your own maintenance plan.
