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 actually 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.
Under the hood 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.
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.
When Multisite buries you
None of the above saves you if the preconditions are wrong.
The most common failure I see in Multisite proposals is plugin incompatibility. 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. Multisite doesn’t.
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 to get a clear answer from your legal team rather than assuming it is fine because the schools are related.
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.
The three questions to answer before the build
Not “should we use Multisite” but three prior questions, in order. 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 (different brands, different audiences, different voices), 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 actually run the network. Without that, the savings are theoretical.
Are there any legal or data-separation obligations that push against shared infrastructure? This requires a clear answer from your legal and compliance team, not an assumption. 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 actually 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.
Leave a reply