IOMAD vs Moodle Workplace

Where I stand, before you read any further

Hooknot Digital is not a Moodle Partner of any tier, Premium or otherwise. I cannot sell you a Moodle Workplace licence, I earn nothing if you buy one, and I earn nothing if you do not. I do not resell IOMAD either.

That is precisely why this page is worth your time. Many of the detailed comparisons you will find are published either by a Premium Certified Partner whose revenue depends on Workplace seats, or by a hosting shop whose revenue depends on you choosing IOMAD. My interest is narrower: I want to know which platform is cheaper and calmer to keep alive over several years, because on the open source path the person eventually asked to make it behave is someone like me.

Everything technical below was checked against Moodle's own documentation, IOMAD's documentation site, the IOMAD source tree and the Moodle Marketplace on 21 August 2026. Version numbers move. Re-check them before you sign anything.

What each product actually is

IOMAD

IOMAD is an open source multi-tenancy distribution of Moodle, developed and maintained by e-Learn Design, a Moodle Certified Partner based in Glasgow. Its published release history runs back to September 2011, when the product shipped under the name Perficio; the IOMAD name arrived with version 2.5 in November 2014. It is released under GPL v3 or later, the same licence as Moodle itself.

The important architectural fact, and the one that is easiest to get wrong: IOMAD is not a bag of plugins you drop onto a stock Moodle. It is a fork. The IOMAD repository merges the corresponding MOODLE_XXX_STABLE branch from Moodle HQ and then applies its own changes on top, including edits to core files. In the 5.1 tree, the import block at the top of public/lib/moodlelib.php reads use block_iomad_commerce\helper as iomad_commerce; use core\di; use core\hook; use local_iomad\{company, iomad}; — two of those four imports belong to IOMAD, not to Moodle — and the file carries company-aware branches for outgoing mail configuration and user handling. You run IOMAD's code base, not Moodle's.

On top of that core, IOMAD ships more than thirty of its own plugins: local_iomad, twelve block_iomad_* blocks including block_iomad_company_admin, enrol_license, mod_trainingevent, mod_iomadcertificate, auth_iomadsaml2, auth_iomadoidc, ten local_report_* reporting plugins, and three IOMAD themes.

One detail worth holding on to, because it tells you something about the two products' relationship: Moodle's own partner page for e-Learn Design and e-Learn Design's own website both describe the company as a Moodle Certified Partner, and neither carries a Premium designation. Premium is the tier required to sell Moodle Workplace. On the public listings, then, the organisation that maintains the open source option is not in the tier that could sell you the commercial one.

Moodle Workplace

Moodle Workplace is a commercial product built and owned by Moodle HQ. Moodle's documentation says it is "available through Moodle Certified Partners and Service Providers only". Moodle's commercial pages are narrower and more useful: "Only Premium Certified Partners can offer Moodle Workplace, our enterprise learning management platform." Premium is a distinct partner tier, so approach an ordinary Certified Partner and they will turn you away. Workplace is not on the Moodle Marketplace, there is no download link, and there is no public price list.

Technically, Workplace is more than a plugin set, and getting that wrong distorts everything downstream. Moodle's own installation documentation describes the Workplace package as three things: Moodle LMS of the latest minor version, several core modifications that are either future core fixes or Workplace-only patches letting the plugins hook into core, and a number of Workplace plugins including the theme. The documentation is explicit that deploying the plugins without the core modifications costs you functionality.

So both products patch Moodle core. The difference is degree, not kind. Workplace is a contained set of targeted patches maintained by the same organisation that maintains core, and merged forward by them each release. IOMAD is a fork of the entire tree, merged from upstream each cycle by a third party. That single distinction explains almost everything downstream in this comparison: the upgrade lag, the plugin-conflict risk, and why both exit routes require you to swap the code base rather than just uninstall some plugins.

IOMAD vs Moodle Workplace at a glance

How tenancy actually works in each

This is where the two products genuinely diverge, and it is the decision that is hardest to reverse later.

Workplace enforces one tenant per user account. The documentation states it plainly: "A user cannot be assigned to more than one tenant; an account always belongs to a single tenant and a single tenant only." Users can be moved between tenants by someone holding tool/tenant:allocate, a capability that, in Moodle's words, "may only be applied in the system context", and the same field can be set through a CSV user upload, where a tenant is matched by its tenant ID number. A user cannot be left tenantless, and cannot straddle two tenants at once. Courses can be shared across tenants; people cannot.

IOMAD allows a user to belong to several companies. Its local_iomad_company_users table carries a unique index on (companyid, userid, departmentid), so a single user row can hold multiple company allocations, each with its own department and its own managertype: 0 for a learner, 1 for a company manager, 2 for a department manager. IOMAD companies also nest, through a parentid column, so a parent organisation can oversee its subsidiaries.

Ask yourself the awkward question early: does the same human being ever need to appear in two client organisations at once? A freelance trainer delivering for three of your customers, an auditor with cross-tenant visibility, a consultant on secondment. If the answer is yes, IOMAD's model fits and Workplace's does not, and you will spend the next three years creating duplicate accounts to work around it. If the answer is a firm no, Workplace's stricter isolation is a feature, not a limitation. I have written more about how IOMAD multi-tenancy is set up in practice if you want the configuration detail.

IOMAD also gives you local_iomad_company_role_restrictions, a per-company and per-role list of capabilities that are disallowed inside that tenant — the table carries both a companyid and a roleid, with a unique index across role, company and capability. That is a blunt but useful instrument if a client requires that their own company managers can never delete a user, while your support role keeps that power.

Licensing and the true cost of ownership

IOMAD's licence cost is zero. That is real, and it is not the whole picture. Your actual bill is hosting, backups, monitoring, the person who applies security patches, and the person who fixes it when an upgrade goes sideways. On a serious multi-tenant deployment that is not a rounding error.

Workplace's licence cost is unknown until you ask. Moodle publishes no price. Premium Certified Partners quote it, typically as an annual fee banded by user tier, bundled with hosting and a support agreement. You will find third-party blog posts confidently quoting monthly figures; they disagree with each other wildly for the same scope, which tells you the only number worth anything is the one on your own quote. Get at least two partner quotes and insist that hosting, implementation, integrations and support renewal are itemised separately, because that is where comparisons break down.

The honest way to compare is total cost over three years, not licence versus zero:

• IOMAD: infrastructure, plus an administrator's time, plus a retained developer for upgrades and incidents, plus any custom work you would otherwise have got as a Workplace feature.
• Workplace: licence, plus partner hosting, plus implementation, plus integration work, plus renewal increases, minus the internal engineering time you no longer spend.

For a small operator running five or ten tenants, the absence of a licence fee is hard to outweigh. For a 5,000-seat compliance-driven organisation with an audit obligation and no in-house LMS engineer, the Workplace bill can be the cheaper of the two once you price a competent administrator honestly.

Features that genuinely differ

A lot of what gets sold as a Workplace differentiator is now in Moodle core and therefore in IOMAD too. Custom reports built on the report builder, competencies, badges, and the AI subsystem all live in Moodle LMS. IOMAD 5.1 carries the core AI subsystem at public/ai, inherited from Moodle 5.1 like the rest of the tree. Discount those from any sales deck you are shown.

What Workplace genuinely has that IOMAD does not:

• Dynamic rules. A rules engine with conditions and actions spanning cohort membership, course completion and enrolment, jobs, departments, positions, programs and certifications. This is the single strongest argument for Workplace. There is no equivalent in IOMAD or core; you replicate it with scheduled tasks and custom code, and that code becomes yours to maintain.
• Programs and Certifications as first-class objects, with validity periods, automatic recertification windows and overdue indicators. IOMAD's learning paths cover the sequencing but not the compliance lifecycle to the same depth.
• Organisation structure as departments, positions and job assignments, which is what produces genuine reporting lines and team dashboards for line managers.
• Migrations, described in the documentation as the capacity to export parts of a Workplace instance and import them into the same or a different site.
• The Workplace App, branded and tenant-aware, on iOS and Android.

What IOMAD has that Workplace does not, or does differently:

• Course licences via enrol_license, a seat-allocation model where a company buys a block of course places and a manager hands them out. If you sell training to organisations, this maps to your commercial model far better than anything in Workplace.
• Per-company authentication. auth_iomadsaml2 and auth_iomadoidc let each tenant point at its own identity provider.
• Per-company outgoing mail. IOMAD patches core mail handling so SMTP host, credentials and no-reply address can be set per company.
• Built-in e-commerce through block_iomad_commerce, with a per-company ecommerce toggle.
• Nested companies and multi-company users, as above.

One practical note worth money: certificates are not a reason to buy Workplace. The Workplace team publishes tool_certificate (Certificate manager) and mod_coursecertificate on the Moodle Marketplace, free and GPL-licensed like everything else there, supporting Moodle 3.9 to 5.2, and stating in their own listings that they are fully compatible with Moodle LMS. You can have Workplace-quality certificate templates on IOMAD or on plain Moodle at no cost.

Hosting freedom and vendor lock-in

IOMAD imposes no hosting constraints. It installs like any Moodle: your own VPS, your own AWS or Azure account, a colocated box, whatever satisfies your data residency rules. You hold the database, the moodledata directory and the code. If you fall out with your supplier you change supplier, not platform.

Workplace is deployed and hosted through Premium Certified Partners. Moodle's position is that it is not available for self-installation. Whether a given partner will deploy into infrastructure you own and control is a question to put to them directly and in writing, along with what happens to that deployment if you terminate. Do not assume; it is not a right the licence hands you by default.

This is the lock-in axis, and it is worth being precise about what is actually locked. Your content and learner records are not locked in either product, because both sit on the standard Moodle schema. What is locked with Workplace is the code and the operational relationship: the LMS build with its core modifications comes through the partner, the hosting comes through the partner, and the renewal comes through the partner. The core patches matter here more than people assume — they are why you cannot simply take the plugins somewhere else and carry on.

Upgrade cadence, and how each tracks Moodle core

This is the section where the difference is measurable rather than rhetorical, and on the dates checked here it favours Workplace.

Moodle 5.2 was released on 20 April 2026. As of 21 August 2026, the stable core branch is MOODLE_502_STABLE at release 5.2.2+, Build 20260818. Moodle Workplace tracks that closely: Workplace 5.2.2 landed on 11 August 2026 against Moodle LMS 5.2.2. Since Workplace 4.1, Moodle has packaged two variants of each major — a standard version that receives bug and security fixes only for as long as the matching LMS version is supported, and a rolling version that keeps gaining features until the next LMS major, then gets four further months of bug fixes before support stops entirely. Ask your partner which one you are being quoted, because it changes what arrives on your site mid-contract.

IOMAD's most recent branch is IOMAD_501_STABLE, sitting at IOMAD 5.1.6, Build 20260810. There is no IOMAD_502_STABLE branch. Four months after Moodle 5.2 shipped, IOMAD's newest published line was still 5.1. That is not neglect: the branch is actively maintained, with core merges from moodlehq/MOODLE_501_STABLE and IOMAD bug fixes landing on 10 August 2026. It is simply how a third-party fork of an entire tree works.

IOMAD does publish a target, so you can measure it against its own yardstick rather than against a guess. Its documentation states that "The target release dates for new IOMAD versions are 3 months after each Moodle release", and that Moodle's two-monthly point releases are folded into supported IOMAD branches "within the next working day". Within a line, that holds up: IOMAD 5.1.6 matches Moodle's own latest 5.1 point release. The majors have run wider than the three-month target more often than not. Moodle 4.5 shipped on 7 October 2024 and IOMAD 4.5 in February 2025. Moodle 5.0 shipped on 14 April 2025 and IOMAD 5.0 in July 2025. Moodle 5.1 shipped on 6 October 2025 and IOMAD 5.1 in March 2026. Plan for a lag of three to five months on a major, and treat the published target as an intention rather than a commitment.

Here is the consequence that matters most, and it is the one easiest to miss. Moodle 5.1's general support ends on 5 October 2026, after which it receives security fixes only, until 19 April 2027. Deploy IOMAD 5.1.6 and the core line underneath you leaves general support on that date. Moodle 5.2, which Workplace is on, has general support until 19 April 2027 and security support until 4 October 2027. That is roughly a six-month difference in remaining life on each of those two clocks.

Plan your calendar around that. If you need a Moodle feature the day it ships, IOMAD will frustrate you. If you upgrade annually anyway and you are comfortable running part of the year on a security-only line, the lag costs you little.

The platform requirements you inherit differ between those lines, which matters when you size a server:

Both lines require 64-bit PHP, the sodium extension, and max_input_vars set to 5000 or above. IOMAD inherits the Moodle 5.1 column wholesale, because it is that code base with changes applied on top; it adds no database requirement of its own. Moodle 5.3 is the next LTS, scheduled for 5 October 2026 — the same day Moodle 5.1 drops out of general support — with general support to 4 October 2027 and security support to 1 October 2029. If you are starting a build, targeting the LTS is usually the calmer plan. That reasoning is the same one I apply to Moodle upgrade work generally.

To find out exactly what you are running, on either platform, from the installation root:

# Moodle release string
php admin/cli/cfg.php --name=release

# Which IOMAD branch is checked out
git branch --show-current

# Is this actually IOMAD? Prints a version number if local_iomad is installed;
# otherwise prints "No such configuration variable found." and exits with status 3
php admin/cli/cfg.php --component=local_iomad --name=version

All three read rather than write, so none of them stop on a confirmation prompt. In the Moodle 5.x layout admin/cli still sits at the installation root, above public/, so these run from the same place they always did.

Plugin compatibility

Both platforms run standard Moodle plugins, and both hit the same wall: the Moodle plugin ecosystem lags major releases. A concrete example, checked on 21 August 2026. Face-to-face (mod_facetoface), the long-standing open source classroom-booking module with Catalyst IT as lead maintainer and Dan Marsden as maintainer, declares support for Moodle 2.6 to 4.5 on the Moodle Marketplace. It has not been published for the 5.x line at all. If instructor-led training is central to you, that gap is a live risk on the open source path, though IOMAD softens it by shipping mod_trainingevent in the distribution.

The IOMAD-specific hazard is the size of the fork. Because IOMAD patches core files across the tree, any third-party plugin or theme that also expects to patch core, or that overrides the same renderers IOMAD overrides, can conflict. Themes are the most exposed, because IOMAD ships three of its own and overrides core renderers to do it. Test every third-party plugin on an IOMAD staging copy, never on a stock Moodle staging copy, because the two are not the same code.

Workplace carries a milder version of the same risk — it has core modifications too — but yours is mostly commercial: your partner controls what is installed. Ask, before signing, what their policy is on third-party plugins, who tests them against each Workplace release, and whether a plugin you depend on can block your upgrade.

Migration paths, in and out

Into IOMAD from plain Moodle. Straightforward in principle: stand up IOMAD of the matching version, restore your database and moodledata, run the upgrade so IOMAD's plugins install their tables, then create companies and allocate users. The work is not the migration, it is deciding how your existing categories, cohorts and roles map onto companies and departments. Budget for that decision, not for the file copy.

Into Workplace from plain Moodle. Documented and supported, and performed by your partner. Because Workplace is the same Moodle LMS with core modifications and plugins layered on, an existing Moodle site can be upgraded to Workplace of the same or higher version by the usual code-swap process — but the code you swap in must include the core modifications as well as the plugins, and Moodle's documentation warns that omitting them costs you functionality. Moodle's installation documentation also notes that you can set $CFG->forcewpsetup = true; in config.php beforehand, so the upgrade adjusts core roles, changes the default course category, and adds the myinprogress and myavailable blocks to the default dashboard, resetting it for all users. Without that flag you make those changes by hand afterwards.

Out of Workplace. Yes, you can leave, and this is the question every buyer should ask out loud before signing. Moodle documents the route: reset the default theme and course format to non-Workplace values, uninstall each Workplace plugin — some depend on others, so the uninstall link only appears once the dependants are gone — then perform a normal upgrade onto Moodle LMS code of the same or higher version, which is what replaces the modified core with a clean one. Afterwards you restore moodle/category:viewcourselist to the Authenticated user and Guest roles if you need it, remove the leftover Workplace roles, reset the mobile app settings and uninstall the Workplace language packs.

What survives is everything in the core schema: users, courses, activities, grades, completions, files. Manual enrolments persist. What is destroyed is everything held inside the Workplace plugins, which the documentation lists as reports, tenant information and configuration, and organisation structure and jobs — and alongside those, user tenant allocations, roles held in course category contexts, program and certification configuration, and your dynamic rules. Courses fall back to whatever the new default format is.

Read that again, because it is the real cost of the exit. Your compliance history as course completions comes with you. Your compliance history as certification records with validity periods does not. If you are in a regulated sector, export that data to something durable on a schedule, from day one, and do not wait until the month you decide to leave.

Out of IOMAD. Structurally the same shape, and no easier. Uninstall the IOMAD plugins and move to a stock Moodle code base of the same version. Core data survives; company allocations in local_iomad_companies and local_iomad_company_users, licence records and IOMAD reporting do not. If anything the code step is heavier than Workplace's, because you are replacing a whole forked tree rather than a contained set of patches, and the fork has been diverging for as long as you have been running it. Test on a clone first, always.

Support model

With Workplace, support is the product as much as the software is. You have a contract, a named Premium Certified Partner, an escalation path, and in most agreements a service level. When something breaks at midnight, there is someone whose contractual job it is to answer. You are paying for that, and for many organisations it is the entire justification.

With IOMAD, support is whatever you arrange. e-Learn Design offer commercial support and hosting for the product they build, which is the closest equivalent to a partner relationship. Otherwise you use the community forums, the GitHub issue tracker, or an independent Moodle developer on retainer. The ceiling is high and the floor is low: a good independent will read the source and fix the actual bug, but you have to have found that person before you need them, not during the incident.

There is no third option where nobody maintains it. Multi-tenant Moodle carries other people's compliance data. Decide who is responsible before you go live.

Which should you choose

Choose IOMAD if

• You sell training to organisations and need a seat-licence model where a client buys places and distributes them.
• The same person sometimes belongs to more than one client organisation.
• You need nested parent and child organisations.
• Data residency, procurement rules or budget mean you must host it yourself.
• You have, or are willing to retain, someone who can read Moodle source and run a server properly.
• An upgrade lag of three to five months behind a Moodle major costs you nothing, and you are comfortable spending part of that time on a core line in security-only support.
• Your automation needs are covered by reminders, learning paths and scheduled tasks rather than a rules engine.

Choose Moodle Workplace if

• Compliance is the point: certifications with validity periods, automatic recertification, audit-ready evidence.
• You want dynamic rules to remove manual administration, and you would otherwise be paying a developer to build that engine.
• You need real reporting lines, job assignments and manager dashboards out of the box.
• You want a contractual support relationship and a name to escalate to.
• Tenants must be strictly isolated, with no user ever spanning two.
• You have no in-house LMS engineering capacity and no appetite to acquire any.
• You want to be on a currently supported Moodle version as soon as it ships.

Choose neither if

You have one organisation and no genuine tenancy requirement. Plain Moodle LMS with course categories, cohorts and cohort sync solves more problems than people expect, at a fraction of the operational weight of either product. Multi-tenancy is a cost you should only pay when separation is a hard requirement, not a tidy-looking one.

A checklist to run before you commit

1. Write down the number of tenants at launch, and honestly at year three.
2. Answer the multi-tenant user question. Yes or no, in writing.
3. List your compliance obligations. If certifications must expire and re-trigger automatically, price the cost of building that on IOMAD before you dismiss Workplace.
4. Name the person responsible for security patches. If the answer is nobody, choose the managed route.
5. Get two quotes from Premium Certified Partners for Workplace, itemised: licence, hosting, implementation, integrations, support, renewal terms. Confirm whether you are being sold the standard or the rolling release.
6. Price three years of IOMAD hosting plus retained engineering time against those quotes.
7. Ask any Workplace partner, in writing, what the exit process is and what data is lost. Compare their answer to Moodle's own documentation.
8. Test your must-have third-party plugins on the actual target platform, not on a stock Moodle.
9. Check which Moodle line you will land on and how long it lives. Moodle 5.1 leaves general support on 5 October 2026 and security support on 19 April 2027; Moodle 5.3 LTS arrives on 5 October 2026, with general support to 4 October 2027 and security support to 1 October 2029.
10. Build a staging environment before you migrate anything. Not after.

Getting a second opinion

If you are mid-decision and want someone to pressure-test it who is not selling either product, that is a conversation I am happy to have. I can look at your current Moodle, tell you honestly whether tenancy is even the right answer to your problem, and give you a straight view on what each path costs you to operate. If Workplace is genuinely the right fit, I will say so and point you at Moodle's Premium Partner network, because I cannot sell it to you.

You can book a 30-minute Moodle session, or email rgrover@hooknot.com with what you are weighing up. I reply personally, usually within a working day. That is not a service level, just how a one-person shop works.

You can also see the Moodle work I take on, read a bit about my background with Moodle, or just get in touch and describe what is going wrong.