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 knowing 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 your 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.

The version upgrade process

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 the new Moodle version
UAT theme upgraded to the 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 the new Moodle version
Live theme upgraded to the 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 upgrades as a remote service

If you’re self-hosting (either on-premise or with a third-party provider), we can coordinate your version upgrade as an ad-hoc remote service. All of the same steps apply, and the live site upgrade process will be the same, but pre-upgrade preparations may take a little longer, depending on your infrastructure and server OS.