The Moodle version upgrade process
There are a number of reasons to upgrade your Moodle version. It might be necessary as part of a migration to bring your site into line with our standard server builds, or it could be part of a site refresh, bringing you back into line with competitor installations.
Alternatively, it could simply be because your version is approaching the end of active HQ support, so you need to upgrade to stay future-proofed. Whatever the reason, the process remains the same, and this is how to prepare…
Pre-upgrade planning
A version upgrade affects multiple areas, but what that means in terms of post-upgrade activities very much depends on how many versions you need to jump. If you’re upgrading as part of an LMS migration, there’s a page that covers that particular planning process here, but all upgrades involve the following:
Version upgrades apply to themes, too… Particularly if you have a paid-for theme, you’ll need to get a new version that is compatible with your new version of Moodle in advance of the upgrade. When you pay for the new theme, it will download as a zip file; you’ll need to pass that over so it can be applied as part of the upgrade process.
There will be downtime… Your site will need to be in maintenance mode during the upgrade process. We always coordinate a day/time in advance so you can let users know exactly when and for how long the site will be inaccessible. This also gives you time to customise the message shown if users try to access the site during downtime, if you wish.
Multiple stages might be required… Because each Moodle version has specific PHP/operating system parameters, if your version is particularly old, the upgrade to your final version will need to be in multiple stages to accommodate the minimum/maximum system parameters associated with each version. This might have an impact on overall downtime, but will definitely have an impact on theme…
Multiple stages will need multiple theme versions… Because upgrade parameters also apply to themes, each stage of an upgrade involves a stage-compatible theme version too. If you’re using a paid-for theme (and want to keep using it), you’ll need to confirm that a new version comes as a compatible ‘bundle’ for all previous versions before purchase. If not, you’ll need to buy versions that ‘match’ each stage of the Moodle version upgrade, and pass everything over in advance of your scheduled upgrade timeslot.
Upgrading with a UAT
If your version upgrade is part of a wider project, using a UAT (a private test/staging environment) before a live site upgrade allows you to fully overhaul your learning environment without impacting daily activities. Depending on your hosting level, there may be cost implications to using a UAT, so you’ll need to balance those with the convenience of privacy before making a decision…
Shared server hosting
On shared hosting, a UAT is not provided as standard, but one can be arranged for a pro-rata fee. The cost is based on your live hosting level, as a UAT is a clone of your live site (with or without user data, depending on preference). Fees will apply for as long as your UAT remains active, so if you want to keep it for ongoing testing after live site upgrade, it can be added to your agreement under standard renewal terms.
Dedicated server hosting
With a dedicated server agreement, a UAT (private test environment) is provided as standard. All hosting costs are based on usage, so if the UAT takes you over the recommended 89% maximum usage level, then extra disk space will be added (and charged) accordingly. But if the UAT is built (and removed) before your next invoice due date, then no extra charges will apply.
IMPORTANT NOTE: For dedicated server clients, a same-server UAT is only possible if both Moodle versions (current and upgrade) support the same version of PHP. If they don’t, then a UAT will need to be on a separate server, and pro-rata charges will apply regardless of invoice or renewal dates.
Upgrading with (or without) a UAT
If you choose to use a UAT, the process is staged as Step 1 and Step 2. If you upgrade without a UAT, only Step 2 will be necessary:
Step 1.
UAT created by cloning the live site
UAT upgraded to new Moodle version
UAT theme upgraded to new theme version
Client tests UAT functions
Client confirms go-ahead for live upgrade
Step 2.
A time slot/date for live upgrade is scheduled
Live site put into maintenance mode
Live site upgraded to new Moodle version
Live theme upgraded to new theme version
Live site taken out of maintenance mode
IMPORTANT NOTE: Before starting any upgrade, a full backup is always taken so the upgrade can be rolled back should there be any issues that can’t be mitigated in the agreed-upon downtime slot.
Moodle version upgrade FAQs
Bug fixes for functionality and security issues are provided for all in-support Moodle versions. If your version is no longer supported by Moodle HQ, your site is at risk of reported security issues (which have been fixed in newer versions) being exploited.
For future-proofing and safety, upgrading to keep in active support is always recommended.
Moodle versions have associated operating system (OS) version parameters (PHP/MySQL, etc.), so if your version is particularly old, you’ll need to upgrade to be brought into line with our standard builds.
For shared hosting in particular, not doing so means using a server that isn’t shared with other users, increasing your costs accordingly.
No. As all ELD hosting clients get one free upgrade per 12-month period, we simply include it as part of your first year’s service, and it’s covered by the one-off setup fee.
Possibly… If you simply need to migrate ASAP, then any additional costs associated with providing a non-standard build will be charged pro-rata (per month) for as long as it takes to get you upgraded. Once your upgrade is complete and your site is live, you’ll be back on a standard annual agreement.
In the case of out-of-support PHP/operating system versions, however, an alternative pathway will need to be followed.
We’d recommend individual course migration (rather than site backup/upgrade), and you can read more about how that works here. For context…
1. Each Moodle version has specific PHP/operating system parameters, so upgrading a site will need to accommodate the minimum/maximum operating system parameters of each version ‘jump’..
2. Just like Moodle versions, PHP versions have ‘in support’ lifetimes for security. Once they are out of support, using them creates a security risk, and the older the PHP/Moodle version, the higher the risk.
3. While we have specific servers for dealing with just-out-of-support PHP/OS, following an upgrade pathway for anything older would involve the installation of a series of unsupported PHP versions, which is (obviously) something we’re not keen on…
