University Drupal Multisite Governance: A Working Model

University Drupal multisite governance works when the architecture enforces it. Centralize the platform and brand layers, delegate the content and editorial layers, and choose the separation model (Domain Access, Group, or true multisite) that enforces exactly that split.

Governance fails for a predictable reason. Institutions decide who owns what in a policy document, then pick an architecture that cannot enforce it. Colleges want autonomy. Central IT wants one codebase. Marketing wants one brand.

If you run central web or digital for a university with a dozen or more college and campus properties, this is the decision that determines whether your governance policy survives contact with the colleges.

Why Does Decentralized Governance Fail on University Websites?

Decentralized governance fails when every college runs its own site, because the drift is structural, not a discipline problem. In the implementations we inherit at Vardot, the pattern is consistent: over time, independently managed sites start deviating. Branding becomes inconsistent to the point that I can land on a college site and not be able to tell it belongs to the university at all.

The operational cost compounds it. A university with 30 independent college sites has 30 codebases. A security update that takes one deployment on a shared platform has to be repeated 30 times, and every delayed instance is exposure. An accessibility fix, likewise: solved once on a shared codebase, it is solved everywhere. Solved on a silo site, it is solved on that silo site.

The compliance stakes changed shape in 2026, not size. The US Department of Justice's Interim Final Rule, published 20 April 2026, pushed the ADA Title II deadline to 26 April 2027 for public entities serving 50,000 or more, which effectively means nearly all public universities. The standard is unchanged: WCAG 2.1 Level AA. The DOJ cited resource constraints and the current limits of automated remediation among its reasons for the extension.

A governance model that cannot push a remediation across every college property in one release cycle makes that date materially harder and more expensive to hit.

What Should the University Centralize, and What Should Colleges Own?

A working governance model splits ownership across four layers, and the split follows one rule: centralize what is shared in code, delegate what is local in content.

Image

• Platform layer (central, always). The codebase, module set, security updates, and hosting. Compliance is far easier to maintain at the code level than the content level: fix an accessibility issue once, and it is fixed on every site. Because the platform is open source, the university owns the codebase and the configuration that enforces this split, and can audit both.
• Brand layer (central, cascades). Brand lives mostly in the theme: logo, primary colors, typography. Because all college sites consume the same theme, a change is managed from a single point and cascades everywhere. No college can quietly fork the brand.
• Content layer (delegated). Content is separated per college and owned by that college's editors. Central teams do not write the College of Science's pages, and the architecture should not require them to.
• Editorial layer (delegated within central rules). Each college runs its own workflow, but the roles and permission sets those workflows use are defined centrally and enforced in code.

Enforcement is where this model holds or collapses. On the platforms we build, permission overrides happen at the code level, through configuration deployed with the codebase, not by anyone with an admin screen. That is what turns central policy into an enforced rule.

Multisite, Domain Access, or Group: Which Separation Model Fits?

The separation model decides how much of the four-layer split (platform, brand, content, editorial) is enforced by architecture rather than policy. There are three options, in ascending order of separation.

Table 1. Drupal separation models for universities, compared across codebase, database, users, content sharing, per-campus deviation, update effort, and overhead.

1. Logical separation: Domain Access or Group

Domain Access is a suite of Drupal modules that runs a group of affiliated sites from one Drupal installation and a single shared database, so what separates one college from another is access rather than infrastructure. Its 2.x and 3.x release series both support Drupal 10.2 and higher, including Drupal 11.

The Group module is a Drupal module that creates collections of content and users and grants access permissions on those collections. It fits when the real dividing line is who manages which content rather than separate public sites. Shared content between colleges is a checkbox here, not a copy operation.

2. Physical separation: Drupal multisite

Drupal multisite is a core configuration in which one shared codebase serves several sites, each with its own database, settings, and user table. A separate database per college can even sit in a different geographic location.

Users are separate entities per site under multisite: an admin on one campus site has no login on another, so organization-wide access comes from an identity provider rather than a Drupal role.

That identity pattern is not specific to multisite. On Georgetown University in Qatar, the employee microsite authenticates through the university's own identity solution (Shibboleth) rather than through Drupal accounts, on a platform where Domain Access runs the Center for International and Regional Studies site from the same installation and one administration backend. That migration moved roughly 2,000 pages and more than 800 publications with permission levels preserved.

3. No separation: separate silo sites

Separate silo sites share nothing: not code, not theme, not users. This is not a governance model. Independent codebases drift apart in brand, lag on security updates, and multiply every compliance fix by the number of sites.

My rule here is more direct than this usually gets stated: for a typical college structure, I do not think full multisite is worth it. It buys flexibility you may not need at the price of maintenance and hosting overhead you will definitely pay. Logical separation covers the majority case.

Multisite earns its overhead only when you need hard separation, and the clearest trigger I see is the multicampus, multi-country university. One institution operating across more than one regulatory and language environment is where the question becomes real.

My default there is to apply the highest compliance level across all campuses and stay on the safe side. When a specific campus genuinely needs to deviate (a different accessibility regime, a different language set, English only in one country and Arabic plus English in another), multisite is the model that allows that deviation cleanly.

How Do You Consolidate Independent College Sites Onto One Platform?

Consolidation runs college by college, not as one cutover. The sequence is:

1. Build the shared platform first: codebase, theme, role definitions, editorial workflow.
2. Migrate one college as the reference implementation.
3. Move the rest in cohorts against that pattern.

The first college is the expensive one. It settles the content model, the component library, the permission scheme, and the editorial workflow. Every college after it inherits those decisions, which is why per-college effort drops sharply once the reference build is done.

Three variables drive the effort, and raw site count is not one of them:

• Content model variance. Colleges already publishing similar structures (programs, faculty profiles, news, events) consolidate quickly. Colleges with bespoke content types need mapping decisions before any migration runs.
• Per-site custom functionality. Anything one college built for itself has to be re-implemented as a shared component, kept as a scoped exception, or retired. Each answer carries a cost, and the decision is governance, not engineering.
• Integrations. Student information systems, directories, event calendars, and single sign-on are usually the longest pole, because they involve teams outside the web group.

The layer split and the separation-model decision are outputs of Blueprint, the second stage of the Vardot Delivery System, agreed before migration work starts, while the governance model is still cheap to change.

Two sequencing rules I hold to. Order the cohorts lowest-variance first, so the pattern is proven before it meets the hard cases. And treat the platform layer as live from the first migrated college, so security updates and accessibility fixes start flowing on the shared cadence immediately rather than at the end of the program.

One scoping note, offered as planning guidance rather than a quoted figure: price the reference college separately from the remainder. A single blended per-site number hides where the real work sits, and it is the number that most often turns out to be wrong.

Your Separation Model Is Your Governance Model

My position cuts against how this topic is usually framed: university web governance is not a policy problem you solve with a committee and a brand book. It is an enforcement problem you solve in architecture.

Every governance rule that is not backed by the separation model (shared codebase, cascading theme, code-level permission config) eventually gets negotiated away, one college exception at a time. The universities that hold the line are not the ones with stricter policies. They are the ones whose architecture makes the policy the default behavior.

I also do not push multisite by reflex. As a Drupal Diamond Certified Partner, we implement all three separation models across university and multi-property platforms, so the recommendation follows the separation requirement rather than the trend.

How Do Publishing, Brand Updates, and Accessibility QA Actually Flow?

Publishing, brand updates, and accessibility QA on a governed university platform all follow the same pattern: the rails are central, the execution is delegated to the college.

How Does College Content Publishing Work?

I build the workflow around the institution's business need, on Drupal's Content Moderation states: an editor creates a draft, sends it for review, and a reviewer or admin role approves and publishes. Within a governed platform, this works per college without differing from a regular Drupal workflow. Varbase, our Drupal distribution, ships an editorial workflow out of the box that fits what most institutions need without diverging from Drupal core, and it can be extended when an approval chain is longer.

How Do Brand-Component Updates Roll Out?

A brand-component update starts when central design changes the logo, a primary color, or a font in the shared theme. The change deploys once and cascades to every college site. There is no per-college step, which is precisely the point: consistency by architecture.

Where Does Accessibility QA Sit in the Workflow?

Accessibility QA splits along the same line as the governance model: code-level criteria are fixed once in the shared codebase and inherited everywhere, while policy sets the highest applicable compliance level (WCAG 2.1 Level AA for US public institutions) across all properties. Content-level checks live inside each college editorial workflow, at the review state, because content is the layer a shared codebase cannot standardize for you.

Maintaining compliance at the code level is far easier than maintaining it at the content level, so the more of it you can push into the codebase, the less depends on editorial discipline.

What Does Platform Governance Have to Do With AI Readiness?

A governed platform is the precondition for AI readiness, because a shared content model is what makes college content machine-readable. Thirty college sites with thirty content models cannot present a university as one coherent source, either to an external answer engine or to an internal assistant built over institutional content.

Centralizing the platform layer centralizes the things AI systems actually consume: consistent content types and fields, one governed taxonomy, predictable metadata, and stable URLs. Drupal suits this because it enforces structured data, revisions, and content governance by default rather than as an add-on, which is one reason Vardot is a Gold Sponsor of the Drupal AI Initiative.

Accessibility is where the honest limits belong. The DOJ cited the current limits of automated remediation when it extended the Title II date, and that is the right frame: automated and AI-assisted tooling is strong at detection, triage, and regression checks across many properties, and it does not replace human judgment on whether a page is genuinely usable. A shared codebase is what makes the automated half worth running at all, because it means one scan configuration, one fix, and every property inherits it.

Four Questions to Place Your Institution

Four questions, answered against facts you already know about your own institution.

1. Do your colleges need separate editors, but not separate databases, languages, or compliance regimes? Logical separation through Domain Access or Group is your model.
2. Does any campus need to deviate on compliance regime, language set, or data location? That is a multisite trigger, and it is the only one worth paying for.
3. Does anyone own the platform layer today? If no one does, fix that before you choose a separation model. The architecture cannot enforce an owner who does not exist.
4. Are you maintaining more than a handful of independent codebases? Consolidation pays for itself the first time one deployment closes a security advisory everywhere.

Who should own a university web platform?

One central team should own the platform layer: codebase, module set, security updates, hosting, and the role and permission definitions deployed with the code. Colleges own their content and their editorial workflow within those definitions. If no one owns the platform layer today, establishing that ownership comes before choosing any separation model.

The companion governance template turns this into a working document: the four layers, the role definitions, and the decision checklist, ready to adapt to your institution. Download the governance template and pressure-test your current model against it.

If you would rather work through it with someone who has built these platforms, our higher education team is a reasonable next step.