Moodle Case Studies
Four projects, described honestly: what each one actually was, and the reasoning that governs work of that kind. No logos, no invented numbers, no client names.
In short: These four Moodle case studies set out what each project was — a themed academy build, a 3.11 upgrade, a MoodleCloud to AWS migration and a WordPress single sign-on integration — and then the technical reasoning that governs a job of that kind, rather than client logos or invented metrics.
What this page is
These are the four projects I can describe. Hooknot Digital is a one-person studio, so the list is short. You will not find client logos or testimonials on this page, because I do not publish client names.
Each entry is split the same way. First, what the project actually was. Then the reasoning that governs a job of that kind, written as general practice rather than a blow-by-blow account, because I am not going to dress up details I cannot show you. If you are working out whether someone understands Moodle well enough to be handed the keys, the reasoning is the more useful signal anyway. More on who does the work.
A Moodle training site for an astrology and numerology academy
The project. A Moodle training website for an academy teaching astrology and numerology, built on the Edumy commercial theme.
What governs a build like this. A premium theme solves the front end and complicates the back end. Edumy and its peers ship their own blocks and page-building layer, which means extra plugins to track, and a theme that lags a Moodle release can pin an entire site to an old version. Three rules keep that contained:
- Nothing in
/theme/boost/or core gets edited. Overrides belong in a child theme that names the purchased theme in$THEME->parents, so a theme update never silently reverts customisations. - Every bundled plugin is recorded with its component name and version, so upgrade planning later starts from a written inventory rather than from whatever the upgrade screen happens to report.
- Layout is configured through the theme's own settings wherever possible. Custom SCSS is the last resort, not the first.
Get those wrong and the branded site you paid for becomes the reason you cannot upgrade. Get them right and the customisation layer stays isolated enough that the next upgrade is a scheduled job rather than a rebuild.
An upgrade to the Moodle 3.11 line
The project. Taking an older Moodle up to the 3.11 line, released on 17 May 2021.
What governs an upgrade like this. The Moodle upgrade script itself is deterministic; it is the environment around it that blocks an upgrade. Moodle 3.11 requires PHP 7.3.0 as a minimum, and accepts a direct upgrade only from Moodle 3.6 or later — anything older needs a staged hop through an intermediate release before it can touch 3.11 at all. Every line has its own floor, and the floors keep rising:
| Moodle line | Released | Minimum PHP | Minimum MySQL / MariaDB / PostgreSQL | Direct upgrade from |
|---|---|---|---|---|
| 3.11 | 17 May 2021 | 7.3.0 | 5.7 / 10.2.29 / 9.6 | 3.6 or later |
| 4.5 LTS | 7 Oct 2024 | 8.1.0 | 8.0 / 10.6.7 / 13 | 4.1.2 or later |
| 5.2 | 20 Apr 2026 | 8.3.0 | 8.4 / 10.11.0 / 16 | 4.4 or later |
Those are the three engines most sites run; Moodle 5.2 also supports SQL Server 2019 as a minimum. The order of operations does not change, and it is rehearsed on a clone before it is repeated on production. Nothing improvised at the console:
php admin/cli/maintenance.php --enable
mysqldump --single-transaction -u USER -p DBNAME > pre-upgrade.sql
tar -czf moodledata-pre-upgrade.tar.gz /path/to/moodledata
# swap in the new code, keeping config.php and any custom plugins
php admin/cli/upgrade.php --non-interactive
php admin/cli/purge_caches.php
php admin/cli/maintenance.php --disableWorth saying plainly. Moodle 3.11 left general support on 14 November 2022 and security support on 11 December 2023, so a site still sitting on that line receives no fixes for newly discovered security issues. Moodle 4.5 LTS is itself security-only: its general support ended on 6 October 2025 and its security support runs to 4 October 2027. So a move off 3.11 means either 4.5 LTS as a holding position with a known expiry, or the 5.x line, whose long-term-support release is Moodle 5.3, dated 5 October 2026 with security support to 1 October 2029. That is what the Moodle upgrade service exists for.
MoodleCloud to a self-managed AWS server
The project. Moving a Moodle site off MoodleCloud onto a self-managed server on AWS.
What governs a migration like this. Leaving MoodleCloud is a defined path, not a file copy. The Site Export in the MoodleCloud portal produces the site database and its files, puts the site into maintenance mode while it runs, can take several hours depending on the size of the database, and delivers a download link by email. MoodleCloud cannot re-import its own site exports — they exist to move content to a self-hosted Moodle — so it is a one-way door, and worth being certain about before you open it.
After that, two rules decide whether the restore is boring or painful. Build the target to match the source Moodle version exactly before restoring anything: you restore into the same version and upgrade afterwards, never the reverse. And put moodledata outside the web root while you have the chance. With the database and files in place, and wwwroot, dataroot and the database settings corrected in config.php, the old host still has to be flushed out of the database itself:
# take a database and site backup first — this rewrites content in place
php admin/tool/replace/cli/replace.php \
--search=//old.moodlecloud.host --replace=//new.host \
--shorten --non-interactive
php admin/cli/purge_caches.phpWithout --non-interactive the script stops on a confirmation prompt, which matters if you are driving the cutover from a script rather than a keyboard.
Cron is the piece that changes hands. MoodleCloud runs it for you; a self-managed server does not, and a Moodle without cron degrades quietly rather than failing loudly. It belongs in the web server user's own crontab — crontab -u www-data -e on a Debian or Ubuntu box — so that the files it writes carry the right ownership, and it runs every minute:
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/nullWhat you get in exchange for that extra responsibility is the point of the exercise: root access, your own backup schedule, and the freedom to install plugins the hosted tier will not permit.
WordPress and Moodle with single sign-on
The project. Integrating a WordPress site with Moodle so that one sign-in works across both.
What governs an integration like this. The route matters more than the implementation, because single sign-on decisions are painful to reverse once accounts exist and people have logged in under them. There are four routes on the table, and only three of them are actually options:
| Route | Where identity lives | Fits when |
|---|---|---|
| OAuth 2 — a custom issuer in Moodle's OAuth 2 services, consumed by the OAuth 2 authentication plugin | WordPress, which needs an OAuth 2 server plugin to act as the issuer — it is not a core capability | Accounts already exist in WordPress and you want one login for both |
LTI Advantage — Moodle's Publish as LTI tool (enrol_lti) with the LTI authentication plugin enabled | The launching platform, with Moodle as the tool | Learners launch from a platform that already speaks LTI 1.3 — WordPress does not do this natively and needs a third-party platform plugin — and should never see a Moodle login screen |
| A commercial bridge plugin pair | WordPress | You need enrolment and product sync, not only sign-in |
Shared cookies or direct writes to mdl_user | Nowhere safe | Never. It breaks at the next upgrade, and it breaks quietly |
Whichever route fits, it should run through Moodle's supported authentication layer rather than around it. That is the whole difference between an upgrade being a routine evening's work and an upgrade being the day everybody's logins stop working.
What a typical engagement looks like
- A call. Thirty minutes, free, no pitch. Sometimes that is the whole engagement: a setting to change, and no invoice.
- A look at the actual site. Moodle version, PHP version, database engine and version, the plugin list, cron health, and how backups are currently taken.
- A written plan. What will change, in what order, what gets backed up first, and what the rollback is.
- Rehearsal on a clone. Anything touching production is done twice: once where it does not matter, once where it does.
- Handover. Commands, paths and decisions written down, so your team is not dependent on me for the next routine job.
Beyond one-off projects, the work I take on is Moodle administration, custom SQL reporting through the Ad-hoc database queries report, and multi-tenant setups. If you are running training for several client organisations, start with Moodle multi-tenancy with IOMAD or the comparison of IOMAD against Moodle Workplace. The full list of what I take on is on the services page. If your situation does not resemble any of the four above, describe it to me or email me directly, and I will tell you honestly whether it is something I can help with.
Common questions
- Why are there no client names in these Moodle case studies?
- Hooknot Digital is a one-person studio and client work is not published by name. Rather than fill the gap with logos or invented statistics, each entry states what the project actually was, and then sets out the reasoning that governs work of that kind as general practice. If you are assessing whether someone can be trusted with your Moodle, that reasoning is a better signal than a wall of unverifiable badges.
- Can I upgrade my old Moodle directly to the latest version?
- Usually not in one hop. Moodle enforces upgrade paths: 3.11 accepts a direct upgrade only from 3.6 or later, 4.5 LTS only from 4.1.2 or later, and 5.2 only from 4.4 or later. Older sites need staged upgrades through intermediate releases. The environment matters just as much, and each line has its own floor: Moodle 4.5 LTS needs PHP 8.1.0 with MySQL 8.0, MariaDB 10.6.7 or PostgreSQL 13, while Moodle 5.2 needs PHP 8.3.0 with MySQL 8.4, MariaDB 10.11 or PostgreSQL 16.
- How do you migrate from MoodleCloud to your own server?
- Use the Site Export in the MoodleCloud portal, which produces the site database and its files. The site goes into maintenance mode during the export, it can take several hours depending on the size of the database, and a download link arrives by email. Note that MoodleCloud cannot re-import its own site exports, so this is a one-way move. Build the target server to match the source Moodle version, restore into it, fix wwwroot and dataroot in config.php, back up the database and then run the search and replace tool at admin/tool/replace/cli/replace.php with --shorten and --non-interactive, add Moodle cron to the web server user's crontab so it runs every minute, purge caches, and only then upgrade.
- Is Moodle 3.11 still safe to run?
- No. Moodle 3.11 was released on 17 May 2021, left general support on 14 November 2022 and left security support on 11 December 2023, so it receives no fixes for newly discovered security issues. If you are still on it, plan a move. Moodle 4.5 LTS is security-only itself, with general support ended on 6 October 2025 and security support running to 4 October 2027, so it works as a holding position with a known expiry. Otherwise go to the 5.x line, whose long-term-support release is Moodle 5.3, dated 5 October 2026 with security support to 1 October 2029.
- What is the safest way to connect WordPress and Moodle with single sign-on?
- Use Moodle's supported authentication layer rather than a shortcut around it. The usual routes are OAuth 2, with WordPress as the identity provider via an OAuth 2 server plugin and Moodle consuming it as a custom issuer through the OAuth 2 authentication plugin; LTI Advantage, using Moodle's Publish as LTI tool with the LTI authentication plugin, which suits launches from a platform that already speaks LTI 1.3 rather than from WordPress itself; or a commercial bridge plugin pair when enrolment sync is also needed. Avoid shared cookies or direct writes to Moodle's user tables, which break at upgrade time and break quietly.
- What happens on the free 30-minute Moodle call?
- It is a diagnostic conversation, not a sales pitch. You describe the problem, and we look at your Moodle version, PHP version, database, plugin list, cron health and backup situation. Sometimes that is the whole engagement: a setting you can change yourself, and no invoice. If the work is bigger than that, you get a written plan covering order of operations, backups and rollback before anything is touched.
Talk it through with Rohin
Bring the messy version of the problem. A free 30-minute session is usually enough to tell you whether it is a small fix or a real project, and what it would take either way.