Moodle

Moodle upgrade services for sites that fell behind

We take Moodle sites from an old release to a supported one, through the required intermediate steps, with plugins and theme audited first and a rollback ready on the day.

  • Rehearsed on staging
  • Plugin audit included
  • Rollback plan tested
Get a free quote See our work
What is included
  • Upgrade path planning
  • Server requirements
  • Plugin audit
  • Theme compatibility
  • Staging rehearsal
  • Rollback plan
Get a free quote Reply within one business day. NDA on request.
The problem

Why Moodle upgrades keep getting postponed

Moodle upgrades get postponed for understandable reasons. The site works. The theme was expensive. Someone remembers the last attempt, which ended with a white screen and a restored backup. So one skipped release becomes four, the installed version stops receiving security fixes, and the server is still on a PHP version the hosting company keeps threatening to remove.

By then the upgrade is no longer a button. Moodle only upgrades from certain earlier releases, each release needs particular PHP and database versions, and every plugin on the site has to exist in a compatible form at each stop along the way. That is a project, but it is a predictable one when done in the right order. This page describes that order. If custom code edited inside core is part of what is holding you back, we deal with that under Moodle customization.

  • Too many releases behind

    The site cannot jump straight to the current release. It has to pass through intermediate ones, and nobody has mapped which, or what each stop demands from the server.

  • A theme that will not follow

    The theme was written for an old interface. On a newer release the navigation breaks, blocks vanish and the vendor no longer publishes updates for it.

  • Plugins of unknown status

    Dozens of plugins were added over the years. Some are abandoned, some were replaced by core features, and one of them will stop the upgrade halfway if it is not handled first.

  • No safe place to try

    There is no staging copy, so the only way to find out what happens is to upgrade production and hope the backup restores.

What we do

What our Moodle upgrade work covers

An upgrade is mostly preparation. The parts below are done before the live site is touched.

Upgrade path planning

The sequence of releases from where you are to where you need to be, using long-term support releases as stepping stones where the required route allows it.

Server requirements

PHP version and extensions, database engine and version, and configuration limits checked for each stop, with server changes scheduled into the plan.

Plugin audit

Every additional plugin classified: compatible version available, needs patching, replaceable by a core feature, or safe to remove along with its data.

Theme compatibility

Your theme tested on the target release and either updated, rebuilt as a Boost child theme, or swapped for a standard theme as a temporary measure.

Staging rehearsal

The full upgrade is run on a copy of production with real data, timed, and repeated until it completes without errors or manual fixes.

Rollback plan

Database dump, moodledata snapshot and code backup taken before the live run, with the restore procedure tested so that going back is a known quantity.

Typical projects

Moodle upgrade situations we see

01

Catching up after years

A site several major releases behind is brought to a supported one through the required intermediate upgrades, with PHP and the database moved forward along the way.

02

Routine planned upgrade

A healthy site moves to the next long-term support release during a planned window, with plugins updated and regression tests run on staging first.

03

Upgrade forced by hosting

Your host is retiring an old PHP version. We work out which Moodle release your site needs in order to run on the new one, and get it there before the deadline.

04

Upgrade with a redesign

The old theme cannot continue, so the upgrade is paired with a new child theme, and staff are briefed on what changes in navigation and course editing.

In depth

Planning the route to a supported release

You cannot always go straight there

Each Moodle release states the oldest release it can upgrade from. A site that is far behind has to stop at one or more intermediate releases, and long-term support releases are often the natural stopping points because they stay patched for longer. We read the release requirements, plot the route, and note for each hop what the database upgrade will change. On big sites some hops take hours because large tables are rewritten, and that has to be known before the maintenance window is announced.

PHP and the database move too

Releases support a window of PHP versions, and those windows shift. An old Moodle may not run on a modern PHP, while the target release will not run on the old one. So somewhere along the route the server changes, and the order matters. The same goes for the database: minimum versions rise, and older MySQL and MariaDB installs may need their character set and row format converted along the way. We script these steps and run them in the rehearsal exactly as they will run on the day.

Plugins decide whether the upgrade finishes

Moodle checks plugins before upgrading and will flag any that are missing from disk or declare themselves incompatible. Our audit goes further. For each plugin we find a version for every hop, read its upgrade notes, and test the activities that use it. Abandoned plugins get one of three outcomes: we patch them, we migrate their content to a core activity, or we uninstall them cleanly. Custom plugins written for you are updated to current APIs as part of the work, in the way set out on our Moodle plugin development page.

What we verify after each run

A completed upgrade screen proves little. After the rehearsal we compare user, course, enrolment, grade and completion counts with the source, check that the database schema matches what Moodle expects, run cron and confirm scheduled tasks finish, and walk through a test script: log in, open a course, attempt a quiz, submit an assignment, grade it, download a certificate. Integrations are retested, since single sign-on and web service clients are sensitive to changes.

The day itself

The live upgrade repeats a procedure that has already worked. The site goes into maintenance mode, backups are taken, the scripted steps run from the command line, caches are purged and the checks are repeated. If a check fails and cannot be fixed inside the window, we restore and try again another day. Afterwards we stay close for the first teaching week, when most questions about the new interface arrive, and ongoing Moodle maintenance keeps the site from falling behind again.

Process

A Moodle upgrade in order

  1. 1

    Site assessment

    We record the current release, server versions, plugins, theme, custom code and integrations, and confirm the target release with you.

  2. 2

    Route and audit report

    You receive the upgrade path, required server changes and a decision for each plugin, with effort and risks stated before any work begins.

  3. 3

    Staging rehearsals

    The upgrade runs on a fresh copy of production until it is clean. Your staff test key courses and we fix what they find.

  4. 4

    Live upgrade

    In an agreed window we back up, upgrade from the command line, verify data and integrations, and reopen the site.

  5. 5

    Follow-up

    We monitor errors and task logs after reopening, answer staff questions about interface changes and deliver the updated documentation.

Deliverables

What a finished Moodle upgrade leaves behind

  • A site on a supported Moodle release
  • A written upgrade path and plugin decision list
  • A staging copy that mirrors the upgraded site
  • Tested backups and a documented restore procedure
  • Notes for staff on what changed in the interface
FAQ

Before you upgrade Moodle

Can we upgrade straight to the latest Moodle release?
Only if your current release is recent enough. Each release sets a minimum version it can upgrade from, so older sites have to pass through one or more intermediate releases first. We work out the exact route during the assessment, and the intermediate stops are rehearsed on staging and then run inside one maintenance window.
What happens to plugins that do not support the new release?
Each one gets a decision before the upgrade. Where a compatible version exists we install it. Where the plugin is abandoned we either patch it, move its content to a core activity that does the same job, or remove it. You approve that list, so nothing disappears unexpectedly.
Will our theme still work afterwards?
It depends on how it was built. Child themes of Boost usually need small adjustments. Older standalone or heavily edited themes often do not survive a jump across several releases. In that case we rebuild the design as a child theme, as described under Moodle theme development.
How long will the site be offline?
Long enough to back up, run the database upgrade and verify, which is driven by database size and the number of hops. The staging rehearsal is timed, so we can give you a measured window in advance. Most organizations pick a weekend or a break between terms.
What if the upgrade goes wrong on the day?
Then we restore. Before the live run we take a database dump, a snapshot of moodledata and a copy of the code, and the restore has been practiced. If verification fails and cannot be fixed within the window, the site returns to its previous state and we reschedule after finding the cause.
How often should Moodle be upgraded?
Minor releases with security fixes should be applied as they come out. For major releases, many organizations move from one long-term support release to the next, which gives a stable platform and one planned project at a time instead of constant change. Staying within supported releases is the part that matters.
Related

Moodle Migration

Moodle Theme Development

Moodle Maintenance & Support

Moodle Plugin Development

PHP Migration & Upgrade
Start a project

How far behind is your Moodle?

Send us the release shown in site administration and a list of installed plugins if you can. We reply within one business day with a likely route and the steps to a free quote.

  • Free consultation and quote
  • NDA on request
  • You own the source code
  • Reply within one business day
Prefer to talk first? Book a call WhatsApp wwc@worldwincoder.com
Add budget and timeline optional, helps us quote faster

This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.