Contact a Moodle consultant

Four ways to get in touch

Whichever route you use, the reply comes from Rohin Grover, who has spent seven-plus years installing, administering, migrating and troubleshooting Moodle sites.

What to include in your first message

Send these six things and the first reply can carry an actual assessment rather than a list of questions back.

• Moodle release. The full string, for example 5.2.2 (Build: 20260810), not just "Moodle 5". The build date matters as much as the number, because a site tracking a stable branch between point releases reports a + suffix and a build date of its own — the same branch a week later reads 5.2.2+ (Build: 20260818).
• Hosting and stack. Shared cPanel, a VPS, AWS, MoodleCloud; plus PHP and database versions.
• What is broken, or what you are trying to achieve. The exact error text beats a description of it.
• Deadline. A cohort start date changes the order of work.
• Theme and third-party plugins. Especially anything paid or custom.
• Access. Whether you have SSH, database and admin credentials, or need to involve an IT team.

With shell access, three commands cover most of it:

php admin/cli/cfg.php --name=release
php -v
php admin/cli/checks.php

Paste the output. None of the three asks a question, so they run start to finish without waiting on you. checks.php runs Moodle's own status checks and, invoked bare like this, prints only the results that came back warning, error or critical — which is precisely what belongs in an email. Add -v, its --verbose flag, only if you want every check listed, healthy ones included. Run the two Moodle scripts from the directory holding the top-level admin folder: from Moodle 5.1 onwards that directory sits above the public web root, because 5.1 moved the web-facing code into public/ and pointed the document root there, while admin/cli stayed outside it so the CLI scripts are never web-reachable. Without shell access, Site administration > Server > Environment and the notifications page carry the same detail.

Version context worth stating

Moodle 5.2 was released on 20 April 2026 and, as of August 2026, is the newest stable branch. It requires PHP 8.3 or 8.4 — 64-bit only, with the sodium extension and max_input_vars set to 5000 or more — and its database floors are PostgreSQL 16, MySQL 8.4, MariaDB 10.11 or SQL Server 2019. Those numbers belong to 5.2 and to no other branch. Moodle 4.5 LTS, by contrast, asks only for PHP 8.1 and runs on PostgreSQL 13, MySQL 8.0, MariaDB 10.6.7 or SQL Server 2017, so a stack that is comfortable today may be the actual blocker on the way to 5.2. Oracle is a special case: it was supported through 4.5 at 19c and removed from Moodle 5.0 onwards, so if you are on Oracle, lead with that — it decides the shape of everything else.

4.5 LTS is the oldest branch still receiving security fixes; cover for 4.4 ended on 8 December 2025, and everything below it ended earlier still. If you are on 4.5 or older, say so — that is upgrade work rather than a quick fix, and 5.2 refuses a direct upgrade from anything below 4.4, so a site under that floor needs at least one intermediate hop before the final jump. See the Moodle upgrade service. If you are choosing a release to land on rather than one to leave behind, weigh 5.2 against 5.3, which is scheduled for 5 October 2026 as the next LTS and carries security cover to 1 October 2029.

Multi-tenant sites should also say whether they run stock Moodle or IOMAD, and which IOMAD release. IOMAD carries the version number of the Moodle branch it is built on and ships after it: its own stated target is three months behind each Moodle release, and the gap has run wider than that — IOMAD 5.1 arrived in March 2026 against Moodle 5.1 in October 2025. Two things follow from that single number. It tells you which Moodle you are actually running underneath, and it means the newest Moodle branch will not have an IOMAD build behind it yet, so "upgrade to the latest Moodle" is a different question on an IOMAD site than on a stock one.

What happens next

1. Rohin reads it and replies personally, either with an assessment or with the two or three questions genuinely blocking one.
2. If it is larger than an email, you book the free 30-minute call and screen-share.
3. You get a written scope: what will be done, in what order, what is out of scope, and what he needs from you.
4. Work starts once you confirm, on staging first for anything touching a live site.

No sales sequence and no handover to an account manager. The services and past projects pages show the range.

Response times and time zones

There is no SLA here, because one person cannot honestly promise one. In practice he replies himself, usually within a working day. If it will take longer because he is mid-migration for someone else, he says so rather than going quiet.

He works from India on IST, UTC+5:30, with no daylight saving at this end. The overlap windows below are for the northern-hemisphere summer:

The IST column is the one that stays put all year. The other three move with your own clocks: when London, New York and Los Angeles leave summer time the offset widens by an hour and the same IST window lands an hour earlier on their clocks, and when Sydney switches to AEDT it goes the other way. Send your city and IST-equivalent working hours and the call gets booked in a window that is civil at both ends.

If your Moodle is down right now

Put URGENT at the front of the subject line, or send the WhatsApp message instead of the form. Then, before anyone touches anything:

• Copy the exact error, including any debug backtrace.
• Do not re-run php admin/cli/upgrade.php hoping it clears. A half-finished upgrade is harder to unpick than a stopped one.
• If the site still bootstraps, hold it with php admin/cli/maintenance.php --enable. That writes climaintenance.html into moodledata and sets a flag in the database, so it needs both of those working.
• If the database is unreachable, write that file by hand instead: any climaintenance.html placed in the moodledata directory will do. Moodle looks for it during early bootstrap, before it opens a database connection, and serves its contents as an HTTP 503. If you cannot write to moodledata either, block traffic at the web server.
• Confirm you have a current database dump and a copy of moodledata before any fix is attempted.

The two Moodle commands above carry the same dependency — cfg.php and checks.php each load config.php and open a database connection — so on a site that is down hard they will simply fail. In that case send the web server and PHP error logs instead; they are the more useful artefact anyway. Bring that, and the first reply can be a fix rather than a questionnaire.