WordPress multisite for a school board: when it saves you and when it buries you
In short: WordPress multisite is worth it for a school board when the campuses share one design and one team keeps them current, because updates, users, and security get handled once instead of three times. It turns against you when each site needs to go its own way, or when plugins are licensed per site and the bill quietly multiplies. Decide by how much the sites genuinely share.
The IT coordinator at the Yorkville Group described her last month to me. She was maintaining separate WordPress installs across three schools, and the most recent security patch had gone out to two of them. She had lost track of the third. When she went back to check, Yorkville College was still exposed.
Toronto Film School, Yorkville College, and RCC Institute of Technology were all operating on separate WordPress installs when I started. Each had its own theme and plugin stack, running on its own update schedule. Security patches had to go to all three sites separately, each one another chance to miss the last. Training meant running the same session for each editorial team on its own. When a plugin needed reviewing, it was reviewed once on the site someone was looking at and forgotten on the others.
The answer was WordPress Multisite: one installation that hosted all three schools as separate sites on a shared network. Each school kept its brand and its editorial team. The infrastructure underneath became one thing to maintain instead of three.
That build taught me when Multisite is genuinely the right answer and when it is the thing an agency wants to propose because it looks impressive in a scope document. The difference matters, and it is not complicated once you know what to look for.
This is the WordPress Practice case for WordPress Multisite in multi-campus education. If you are running a single campus with a single WordPress site, Multisite is not your conversation. This is for educational organizations with three or more campuses or institutions asking whether to consolidate.
What Multisite is
One WordPress installation, multiple sites sharing a codebase. They share themes, plugins, user roles, and a network-level admin that sits above all of them. Each site has its own domain and its own editorial team. But under the hood it is one set of files on one server, which means one team running one maintenance cycle across all the sites.
It is genuinely one WordPress, presenting as many websites. That is both its power and its constraint.
I think of it like the plumbing in an apartment building. One set of pipes serves every unit, so when the building books a plumber, every tenant gets their maintenance in a single visit. That is the saving. The cost arrives the day one tenant pours grease down their drain and the whole stack backs up into other units. The pipes are shared, so a problem in one apartment becomes a problem for the building. Multisite shares its plumbing the same way.
When Multisite saves you
At the Yorkville Group, three things made Multisite the right answer.
Security maintenance was the most visible saving. A security patch on a WordPress plugin has to be applied to every install that uses it. On three separate sites, that means three separate maintenance windows, each one a chance to apply a fix to the first two and forget the third. On Multisite, you apply it once. The network-admin applies it everywhere. For a small IT team managing three schools, that difference adds up across a year, and it frees the hours you need for the work that cannot be centralised, such as keeping a school site up when it is under attack.
Training gave the same return. I ran one session for all three editorial teams, into the same interface. If I had been training three separate sites, I would have run three sessions into three different setups, answering the same questions each time. With Multisite, the knowledge transferred from one school directly to another because they were working inside the same system.
Each school kept its own identity. Toronto Film School looked like a film school; RCC looked like a technology college. Under the surface, all three were publishing from the same system. Brand stayed separate. Practice stayed shared.
The maintenance savings Multisite offers only exist if someone is actually doing the maintenance.
When Multisite buries you
None of the above saves you if the preconditions are wrong.
Plugin incompatibility is the most common failure I see in Multisite proposals. On Multisite, plugins are installed at the network level. You install it once and it is available across all sites. The problem is that plugins installed for one school sometimes conflict with what another school needs. If Toronto Film School needs a video-portfolio plugin that conflicts with something RCC requires, that conflict lives inside the same codebase and hits every site on the network. On separate installs, each school chooses its own stack and lives with its own choices. On Multisite, one school’s incompatibility is everyone’s problem.
Performance isolation works the same way. A plugin that adds significant load to one school’s pages can degrade the experience for every site on the network. Separate installs keep those problems contained, and a network shares them, which is why availability planning for an education network has to be done for the whole thing at once.
Data separation is the risk most organizations underestimate. At the Yorkville Group, the schools were all under one organization and the shared database wasn’t a compliance problem. For organizations where different campuses have different data obligations (different student privacy rules, different regulatory environments), a shared database complicates the compliance conversation significantly. The question to ask before procurement is whether any school’s data obligations push against shared infrastructure, and the honest answer often depends on details nobody has looked at since the schools were brought under one roof.
Governance is the quiet one. Multisite is centrally administered. The network admin sits above all the individual sites and has powers that individual site admins don’t. If that network admin function isn’t funded and staffed, things break network-wide, not just per-school. The maintenance savings Multisite offers only exist if someone is actually doing the maintenance.
The plugin-licensing cost most organizations miss
Plugin licensing on Multisite is often network-scoped rather than per-site, which sounds like a saving and sometimes is one. But it depends entirely on the plugin. Some premium plugins licence per-site; on a Multisite network you need a licence for every sub-site, which costs the same as separate installs. Others licence per-installation, which on Multisite means one licence covers all your sites, which is the genuine saving.
The mistake is assuming the licensing math works out without checking. Audit the plugins you intend to run before the build, not after. I have had this conversation on behalf of clients who arrived at procurement with a cost model that assumed Multisite licensing discounts across every plugin they intended to use, and the actual licence terms did not match the assumption.
Side by side, the trade looks like this.
| Concern | Separate installs | Multisite |
|---|---|---|
| Security patches | One maintenance window per site, each a chance to miss one | Applied once, network-wide |
| Training | One session per site, into a different setup each time | One session, one interface, knowledge carries between schools |
| Brand | Each school runs its own theme | Each school keeps its brand on a shared codebase |
| Plugin conflicts | Each school lives with its own choices | One school’s conflict hits every site |
| Performance | Problems stay contained | A heavy plugin on one site can slow every site |
| Data separation | Each site has its own database | One shared database; compliance has to be checked in writing |
| Governance | Each site admin owns their site | A funded, staffed network admin is required |
| Plugin licensing | One licence per install | Per-site plugins cost the same; per-installation plugins cover the network |
The three questions to answer before the build
Three questions, in order, before you commit to a network. They sit alongside the questions a senior buyer should ask on any platform decision.
Are the institutions’ brand and editorial identities genuinely separate, or do they want to present as one organization? If the answer is genuinely separate (their own brands, aimed at different students, written in their own voice), Multisite can handle that. If the schools want to feel like siblings, Multisite is a natural fit. If they want to feel like competitors who happen to share a server, expect friction.
Does central IT have the capacity to be the network admin, and is that capacity funded? Multisite trades individual-site complexity for network complexity. If the network function is not staffed, the trade does not work. The Yorkville Group had a central function that could run the network. Without that, the savings are theoretical.
Are there any legal or data-separation obligations that push against shared infrastructure? Your legal and compliance team has to answer this one in writing. If the answer is yes, figure out whether the obligation can be met with careful Multisite configuration or whether it requires separate installs before you build anything.
At the Yorkville Group the answers were: genuinely separate brands but shared practices, yes central IT was funded, and no hard data-separation blockers. Multisite was right for that combination. Your combination may be different.
What the Yorkville build taught me
The thing I did not expect from a shared network was how knowledge moved across it. When one of the editorial teams at Toronto Film School worked out a better way to structure their image galleries, I could replicate the approach to the other schools because they were inside the same system. When I found a more efficient way to handle the media library at RCC, the fix was available to the whole network. Shared infrastructure created a kind of shared practice that three separate installs would never have produced, because the installs would never have known about each other.
That is what the Multisite optimists are right about. It is not just administrative convenience. It is the beginning of a shared institutional practice, for organizations that are actually ready to share. That last qualifier is the one the proposal rarely examines carefully enough.
Common questions
Is WordPress multisite good for a school board? Often, yes. If the campuses run on a common design and one team is responsible for keeping them patched, a network means one maintenance cycle rather than one per school. The case weakens as soon as a campus wants a stack of its own, or a plugin you depend on charges per site rather than per installation. Start by asking how much the schools actually have in common today.
What is the difference between multisite and separate WordPress installs? Multisite runs many sites from a single WordPress installation with shared core, plugins, and users; separate installs are fully independent. Multisite centralises the maintenance, but it also couples the sites, so one update or plugin affects all of them at once.
How does plugin licensing work on WordPress multisite? It depends on the plugin. Some premium plugins licence per site, so a network needs a licence for every sub-site, which costs the same as separate installs. Others licence per installation, so one licence covers the whole network, which is a genuine saving. Check each plugin before you assume multisite is cheaper.
When should you not use WordPress multisite? When the sites need to diverge on brand, plugins, or team, because plugins are installed once at the network level and one school’s plugin can conflict with another’s. If the campuses want to feel genuinely separate, separate installs are usually cleaner.