One platform, many institutions — without any of them giving up control
A multi-university LMS lets a consortium share infrastructure and a course catalogue while every institution keeps its own domain, its own sign-in and its own reporting boundary. This is what that actually takes — drawn from two national-scale platforms we run in Italy.
Built on GARR · IDEM federated identity · self-hosted PeerTube video · Open Badges & ESCO
What a consortium actually asks for
A single university buying an LMS is choosing a tool. A consortium is choosing a settlement between institutions that do not entirely agree with each other — and the platform has to hold that settlement without anyone feeling overruled. Five questions decide everything downstream.
Whose brand does the learner see?
Their own institution's, at their own domain — even though the platform underneath is shared. Branding is the easy part; expectations about it are not.
Who signs in, against which directory?
Each institution keeps its own identity provider. In our experience nobody is willing to hand over their user accounts, and they should not have to.
Who can see whose data?
An institution will share a catalogue long before it shares a completion report. Decide the reporting boundary before you build anything.
Who decides when we upgrade?
One shared instance means one shared maintenance window for everybody. That is a governance question wearing a technical costume.
Where does the data physically sit?
For public institutions this is frequently a procurement condition rather than a preference — and it constrains the architecture, not the other way round.
Three architectures, and what each one costs you
All three get called “multi-university”. They behave very differently once you are running them — and the decision is expensive to unwind, because reversing it means migrating identities and completion history.
One instance, many domains
Each institution gets its own hostname and theme; underneath, one database, one upgrade, one operations team. Cheapest to run and the easiest place to share a catalogue. The cost is autonomy — an upgrade is an event for everyone at once, and a plugin one institution wants is a plugin everyone gets.
Separate instances, shared ops
Each institution has its own installation, managed centrally with common tooling. Full control over upgrades, natural data separation. The cost is integration — a shared catalogue and cross-institution reporting stop being configuration and become engineering.
A hub with satellites
A shared central platform for what genuinely is common — open courses, credentials, the public catalogue — while each institution keeps its own teaching environment. Consortia tend to arrive here after arguing about the first two, because it separates what everybody agrees on from what nobody will give up.
| One instance, many domains | Separate instances | |
|---|---|---|
| Operating cost | Lowest per institution | Higher, repeated per institution |
| Shared catalogue | Configuration | Integration work |
| Upgrades | One window for everyone | Institution by institution |
| Plugins | One set, shared by all | Chosen independently |
| Data separation | Enforced by permissions | Natural, by architecture |
| Cross-institution reporting | Built in | Needs a data layer |
Federated identity is the integration that matters
Most of the engineering effort in a multi-institution platform goes into sign-in, not into courses.
In European higher education the expectation is SAML, usually via Shibboleth, with each institution acting as its own identity provider and the platform as a service provider. Institutions are typically members of a national federation — IDEM in Italy, with eduGAIN linking national federations internationally — so a working federation membership generally opens access to a very large number of institutions without negotiating each one individually.
Two things reliably cause trouble
- Attribute release. Sign-in succeeding is not the same as the platform receiving the attributes it needs to place someone in the right course at the right institution. Attribute policy is set by each identity provider — so this is a conversation per institution, not a single configuration.
- Account matching. What makes two logins the same person, and what happens when someone belongs to two member institutions at once, has to be settled before enrolment rather than after.
On-premise, and why this sector still asks
In corporate training, on-premise is usually a legacy question. In public higher education it is a current one — procurement rules, data-residency obligations, and national research networks that institutions already fund and trust. The same logic extends past the LMS: lecture video is heavy, expensive and privacy-sensitive, which is why a self-hosted stream is often the only acceptable option.
Credentials that travel between institutions
A consortium creates a problem a single institution does not have: a learner earns something at one member and needs it recognised at another. Open Badges, aligned to the European skills framework ESCO, exist for exactly this — and matter more in a shared platform than a standalone one, because the entire point of the consortium is that learning moves.
Two live references, both at national scale
Rather than describe an architecture in the abstract — here is what was chosen, what it integrates with, and what it runs on.
EduNext — one platform, 45 accredited degrees
Six connected portals covering degrees, professional education, MOOCs, video, a knowledge base and credentials — running over the GARR research network with IDEM federated login and self-hosted PeerTube video.
Read the case study →EduOpen — one Moodle, one MOOC network
A shared MOOC network on a single Moodle platform, with SAML and Shibboleth single sign-on, multilingual courses and consortium-wide certification.
Read the case study →Common questions
What is a multi-university or consortium LMS?
One learning platform serving several institutions at once. Each keeps its own branding, domain and sign-in, while the consortium shares infrastructure and usually a course catalogue. It differs from a standard LMS mainly in identity handling and in how strictly data is separated between members.
Is it better to run one shared instance or separate instances per university?
One instance with multiple domains is cheaper to operate and makes a shared catalogue straightforward, but every institution shares an upgrade schedule and plugin set. Separate instances give full autonomy and natural data separation, at higher cost, with cross-institution reporting becoming integration work. Many consortia settle on a hub for shared services while institutions keep their own teaching environments.
How does single sign-on work across multiple universities?
Through federated identity. Each institution runs its own identity provider and the platform acts as a service provider, normally over SAML with Shibboleth. Institutions usually belong to a national federation such as IDEM in Italy, with eduGAIN linking federations internationally. The real work is less the protocol than agreeing which attributes each institution releases.
Can a multi-institution LMS be self-hosted or on-premise?
Yes, and in public higher education it is often required rather than optional, because of procurement rules and data-residency obligations. National research and education networks make it practical. The same reasoning usually extends to video, which is why self-hosted streaming appears in these projects.
Can Moodle run a multi-university consortium?
Yes. EduOpen runs a 17-university MOOC network on Moodle with SAML and Shibboleth single sign-on. What decides whether Moodle fits is less the platform than the consortium's requirements on autonomy, reporting boundaries and upgrade control.
How do credentials work across member institutions?
Through portable credentials rather than platform-specific certificates. Open Badges are the common mechanism, and aligning them to the European skills framework ESCO makes them meaningful outside the consortium as well as inside it.
For public institutions, these decisions are usually made under a procurement condition rather than a preference — see digital sovereignty in European higher education.
Scoping a platform for a group of institutions?
Whether you are building something shared from scratch or trying to consolidate platforms you already run, the useful conversation starts with the five questions at the top of this page — not with a feature list.
Book a Free Demo