Moodle alternatives for school groups: cost the operation, not the licence

Moodle is free to licence and not free to run. For one school with a systems administrator who knows it well, that is usually a good trade. For a group — a trust, a district, a publisher, a ministry programme — the sums change, because the costs that decide the question are hosting, version upgrades, plugin compatibility across those upgrades, security patching and backups, and because multi-tenancy is not in the core product. The honest comparison against any alternative is total cost of operation, not licence cost.

None of that is a criticism. Moodle is the most widely deployed open-source LMS in education and it earned that: genuinely free, genuinely self-hostable, and full of things no commercial product would build. This is arithmetic, not allegiance.

What running Moodle actually costs

Hosting

A PHP application, a database, a file store, and a cron job that must actually run. Size it for exam week and results day, not the average Tuesday. Then a staging copy close enough to production that a rehearsal means something — staging that has drifted is a rehearsal for a different play.

Version upgrades

Moodle publishes an end-of-support date for every release. Once a version passes it, security fixes stop arriving, so staying current is not housekeeping — it is the security posture. Each major upgrade is a code step, a schema step, a downtime window and a rehearsal beforehand, and skipping a version compounds the work rather than saving it.

Plugin compatibility

The plugin directory is why many institutions chose Moodle, and every installed plugin is a dependency on someone else's release schedule. So an upgrade is a matrix: for each plugin, is there a build for the target release, is it maintained, does it still do the thing teachers built their term around. One unmaintained plugin can hold a whole site on an old version, which is the commonest route to running an unsupported release.

Security patching

Moodle publishes security advisories on a schedule. Self-hosted, acting on them is your job: watch the announcements, judge urgency, apply, verify — sometimes off-cycle, sometimes in a holiday when the person who knows how is away. Underneath sit PHP, the database and the operating system, each with its own patch stream.

Backups

Two different things get called backups: course exports, and infrastructure backups of the database and file store. You need both, and a backup you have never restored is a hypothesis. Then the question that bites a group: can you restore one school without a maintenance window for all the others?

Why multi-tenancy is the thing that breaks at group scale

One school rarely runs into this. A group hits it at about the point where two schools want different things on the same day: a different logo, a different term structure, a different answer to who may see whose data.

A Moodle site gives you structure inside one organisation: categories that nest, cohorts, roles assignable at category level. That is real hierarchy. But it is designed around a single site for a single institution — accounts belong to the site, administration is site-wide, and the version, plugin set and maintenance window are shared by everyone on it. So "each school has its own administrator" tends to resolve, in practice, to "each school has someone we trust not to click the wrong thing".

The questions that expose the gap are boring and concrete:

• Can School B change its logo, colours and login page without touching School A's?
• Can School B's administrator create and delete users who exist only in School B?
• Can a teacher who works two days a week at each school have one account?
• Can the group ask one question across every school and get one answer, without an export?
• When School C leaves the group, can its data, users and content be handed over and then removed?
• Can one school be restored from backup without a maintenance window for the rest?

Every one is answerable in Moodle with enough configuration, or with enough separate installations. The cost is the configuration, or the installations.

The three usual answers, and the trade-off in each

Moodle Workplace

The commercial tier, sold through certified Moodle partners, which adds multi-tenancy. The trade-off: you are now buying a commercial product with a partner in the middle, so the free licence is no longer the reason you are there — compare it against other commercial platforms on equal terms, not as the incumbent. And check how a school group's shape (year groups, guardians, terms) maps onto a product whose design centre is workplace training.

A partner contract

A certified partner hosts, upgrades, patches and answers the phone. The work does not disappear; it becomes a line item with an SLA, often a better trade than a hire. Two limits: it does not by itself add multi-tenancy — that is still Workplace or multiple sites — and cost tends to scale with sites and users, so a group pays roughly per school. Ask what leaving looks like before you sign.

Parallel installations

One Moodle per school. Honestly separate — separate data, branding and downtime — and a school can be handed over by handing over its site. The trade-off is that everything multiplies: ten schools is ten upgrade windows, ten plugin matrices, ten sets of advisories, ten backup regimes. Cross-school reporting becomes an export-and-join exercise, usually a spreadsheet, usually one person who is the only one who knows how it works. A group-wide change is applied ten times and starts drifting by the eleventh month.

Groups rarely decide on parallel installations. They arrive at them, because a fresh site was the fastest way to onboard school number four.

AI through a plugin is not the same as AI in the product

Most AI capability in a Moodle deployment arrives as a plugin: a provider connector, a question generator, a summariser. Plugins are how Moodle has always grown. But three properties behave differently when a feature is attached to the side of a platform rather than built into it.

Grounding

Where does the answer come from? A generic connector passes a prompt to a model and returns text, so it reflects the model's general knowledge rather than your syllabus or your marking policy. Grounding means retrieval over your own material, with citations back to the document a sentence came from. In a group that is a data-boundary problem first: School A's documents must never ground an answer given to School B, and a plugin on a single-site data model has no tenant boundary to respect.

Safety review

Who chose the model, who wrote the prompt, what leaves your infrastructure, how long the provider keeps it, and whether a child's written work is in the payload. With a plugin the answer is whoever wrote it, plus whatever you configured — reviewable, since it is open code, but you are the reviewer, per plugin, at every upgrade.

Audit

A term later, a parent or an inspector asks what the AI did. Can you show what was generated, by whom, from which source, and what a human changed before it reached a learner? A plugin writes to its own tables in its own format, if at all.

Plugins are not the problem. The boundary between AI and data has to be drawn by whatever draws every other boundary, and a plugin cannot draw one the platform does not have.

Costing it honestly

Do not estimate. Open the ticket system and the change log for the last twelve months and count.

annual operating hours, per Moodle site

    major upgrades        (windows per year)   x (hours per window)
  + point releases        (releases applied)   x (hours each)
  + plugin re-testing     (plugins relied on)  x (hours per upgrade)
  + security advisories   (acted on per year)  x (hours each)
  + backup restore tests  (tests per year)     x (hours each)
  + unplanned incidents   (last 12 months, from the ticket system)
  = hours per site per year

  x number of sites you run
  x loaded hourly cost of the people who do it
  + hosting, storage and bandwidth
  + partner or support contract
  = the number to compare against a licence

Count only hours that would genuinely disappear if you moved. Then list separately the group-level questions you cannot answer today — how many learners across all schools finished safeguarding training this term, and which schools are behind.

When Moodle is still the right answer

Often. With an in-house systems team who know Moodle, staying is frequently the cheapest and most defensible choice: full control of the stack, no vendor dependency, and a plugin ecosystem covering pedagogy no commercial roadmap will prioritise. Some procurement rules require open source outright. And migration cost is real — content, question banks, gradebook history, accounts, and the old links printed in a hundred handbooks.

The wrong reason to leave is that one upgrade went badly. The right reason is structural: the group grew, its shape is now the problem rather than the software, and the operating cost is paid by people hired to do something else.

If you do look elsewhere, what to check

Here we are the vendor, so read accordingly. Lurno is a multi-tenant platform built for the shape described above; school groups are the case it was designed around. This is the checklist we would want run against us and everyone else on your list.

• Tenancy model. Ask to see nested organisations created live, not drawn on a slide. In Lurno an organisation can contain further organisations, and a role granted at a branch of that tree cascades down it — a group safeguarding lead is granted once.
• Where isolation is enforced. Application-level filtering is one bug from a leak, so ask whether the boundary is in the database. Lurno's is: separation enforced underneath the platform, set out on the security page.
• Branding and domains. Per-organisation white-label branding and a custom domain with automatic TLS, so each school's login page is its own, and a sub-organisation inherits its parent's branding until it overrides it.
• Sign-on. Be exact, and hold us to it. Lurno has partner sign-on (silent SSO) today; SAML/OIDC SSO, MFA and passkeys are on the roadmap and not available. If your schools sign in through Entra or Google Workspace over SAML, ask every vendor — us included — for dates in writing.
• Standards. SCORM 1.2, SCORM 2004, xAPI and LTI 1.3 are in development in Lurno — modelled in the product, runtime being built. If you hold a decade of SCORM packages, ask that first, not last.
• Commercials. Accounts are created by invitation today; self-serve signup, payments and checkout are designed, not built.
• What a corporate LMS has no reason to build. A guardian portal scoped by data category, certificates with a public verification page, competency frameworks with evidence, and four product languages including Arabic in full RTL.
• Exit. How do you get everything out, in what format, and how long does it take? A vendor who answers that quickly is telling you something.

We keep a fuller side-by-side of Lurno and Moodle, including a plain statement of who Moodle is genuinely better for. If your arithmetic says Moodle stays, that is a good outcome — and you will have the number to defend it at the next budget meeting.