Open source CMS for higher education

Why open source CMS for higher education differs from other sectors

For large university estates, Drupal is the usual fit, while WordPress fits smaller or simpler estates. The decision rests less on features than on three things: how editing is governed across hundreds of department sites, whether the platform can sit behind campus single sign-on, and how far the estate has already moved away from Drupal 7. A web office running many aging Drupal 7 sites should know that Drupal 7 security support ended on January 5, 2025, and that Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. They are migrated into a new site, and themes must be rebuilt. Before choosing a platform, confirm which departments still run Drupal 7, which editors depend on custom modules, and which sites must move first.

Public institutions also face the ADA Title II rule. The DOJ's rule requires state and local government web content to meet WCAG 2.1 Level AA, and an interim final rule published April 20, 2026 set compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts. Whether a given public university falls under the larger or smaller date depends on its own status, so confirm that with counsel. Plan for accessibility testing of shared templates, not only of individual pages, because one inaccessible theme component can affect every department site that uses it. The ADA.gov web rule page is the starting point for the regulatory text.

Student records add a second constraint. FERPA's regulations in 34 CFR Part 99 apply to institutions that receive Department of Education funds, and a contractor may handle education records as a school official only under the direct control and redisclosure limits set in the regulation. Any admissions form, advising portal or student login that touches education records needs access controls that limit editors and vendors to the records they have a legitimate educational interest in, and a disclosure log kept for as long as the records are kept. Ask the implementation partner to show where form submissions are stored, which SSO attributes reach the CMS, and which third-party scripts run on pages that collect student data.

Which requirements shape a university web estate build

This table maps four regulatory and security obligations to what each one means for a university web estate, from accessibility testing to form data handling. Read each row as a build requirement with the evidence an assessor or auditor will expect to see. The main takeaway is that accessibility, access control, logging and retention need to be designed into the multi-site platform from the start, not added per department later.

Requirement	What it asks for	What it means for the build	What to confirm with the institution
ADA Title II (WCAG 2.1 Level AA)	Public universities must meet WCAG 2.1 Level AA for web content. The DOJ interim final rule of April 20, 2026 sets compliance dates of April 26, 2027 (50,000 or more people) and April 26, 2028 (smaller entities and special districts).	Accessibility testing in the release process for shared themes and department content, plus a remediation backlog per site and retained test records.	Which compliance date applies to the institution, and whether it is a public entity covered by Title II.
FERPA school official access (34 CFR 99.31)	Outside contractors may receive education records only under direct institutional control. Institutions must use reasonable access controls so staff see only records tied to a legitimate educational interest.	Role-based access per department on any form, portal or student-facing page, with contractor accounts scoped to maintenance tasks.	Which forms collect student records, and who in each department holds access rights.
FERPA disclosure records (34 CFR 99.32)	Institutions must record each request for and disclosure of personally identifiable information, with the parties and their legitimate interests, for as long as the records are kept.	Audit logging of admin and data-export actions, and a disclosure log for submissions shared outside the department.	How long disclosure logs must be kept, and where they are stored.
GLBA Safeguards Rule (16 CFR Part 314)	Institutions in Title IV aid programs agree in their Program Participation Agreement to follow the Safeguards Rule, which requires a written information security program and multi-factor authentication for anyone accessing an information system.	MFA on all CMS administrator, editor and hosting accounts, and a written security program that covers the web estate and its hosting.	Whether financial aid, loan or billing pages or forms fall within the institution's GLBA scope.
Notification duty (16 CFR 314.4(j))	Where a notification event affects at least 500 consumers, the FTC must be notified within 30 days of discovery.	Incident runbooks for form and portal data exposure, with log retention long enough to scope an event.	Who owns incident notification decisions and how the web team is included.
COPPA (16 CFR Part 312)	Operators collecting personal information from children under 13 need a written information security program, a designated coordinator, annual risk assessments and a written retention policy with a deletion timeframe.	Separate handling for pre-college, youth camp or outreach forms, with minimal fields, deletion jobs and no third-party trackers on those pages.	Whether any site, camp or outreach form collects data from children under 13.
Form submission retention	Retention must match the purpose of collection: records kept as long as reasonably necessary and deleted on a documented timeframe.	Per-form retention settings, scheduled deletion and an export path for records a department must keep.	The retention schedule for each form type, approved by records management.
Editor and admin access control	Named accounts, least privilege and SSO for staff, with MFA on privileged roles.	Central governance over shared modules and themes, with department editors limited to their own sections and removal on staff exit.	Whether campus SSO is available and how departmental editor turnover is handled.

Which CMS fits which university estate

A university with many department sites, a central web team and a shared brand usually needs one platform that can host many sites with a common theme and separate editors per department. Drupal is a strong fit for this pattern. Drupal multisite, or a shared codebase with separate site instances, lets the central team maintain one theme and one set of security updates while each department manages its own content. Drupal CMS, a distribution built on Drupal core with recipes and site templates, can speed up provisioning for new departments, and the core or contributed workflow modules can carry content moderation rules where review is required before publishing.

Shared theme: Keep the design system in one codebase so brand changes and accessibility fixes reach every site in one release.
Provisioning: Use site templates or recipes so a new department site starts with approved content types, menus and permissions.
Editorial roles: Map department editors, reviewers and central administrators to roles that limit each editor to their own sites.
Release cadence: Drupal 11 receives feature releases every six months, and security releases follow the core release schedule, so plan a fixed patch window across the estate.
Hosting model: Confirm who operates the shared environment, who handles upgrades and whether the central team or a partner carries the on-call duty.

Ask any implementation partner to show how a single theme change is tested and released across sites before you commit to a multisite design.

Platforms that fit higher education web estates

Most university web estates run on Drupal, with WordPress appearing in smaller departmental sites and course delivery usually handled by a separate learning platform. The cards below separate the core web platform choices from the adjacent tools that sit beside them, and each card names the check to run before committing.

Drupal core for multi-site estates

Drupal core is licensed under GPL-2.0-or-later and has no paid edition, so the software cost is zero and the budget goes to architecture, theming, migration and support. For a campus with hundreds of department sites, the decision is how many sites share one codebase and one theme, and whether to use Drupal's multisite approach or separate installs. Confirm how the central team will push core and contributed module updates across every site on the schedule in the core release calendar, and who tests them first.

Drupal CMS 2.0 for department editors

Drupal CMS is a distribution built on Drupal core that bundles recipes, site templates, the Drupal Canvas visual page builder and optional AI tools. It suits department teams that need to build landing pages without developer help, but it is a starting point rather than a finished campus standard. Confirm which recipes and contributed modules your governance model allows, and whether the Canvas components produce markup that passes your accessibility checks.

WordPress for small departmental sites

WordPress 7.1.3 was released on October 6, 2026, and WordPress.org maintains only the latest release in the 7.1 series, so the upgrade path is a standing operational task. Many departments already run WordPress sites, and a central team may accept it for low-complexity sites with few editors. Confirm whether the campus will allow it under the same governance and accessibility rules as the Drupal estate, and who owns plugin review, since plugin quality varies widely.

Moodle 5.3.0 for course delivery

Moodle is licensed under GPL-3.0 and is designed for course delivery, so it belongs beside the web estate rather than inside it. Moodle 5.3.0 was released on October 5, 2026 and is the next long-term support release, with security fixes until October 1, 2029. Confirm how course pages link to the main site, how single sign-on passes student identity, and how course content is audited for accessibility, since learning content often falls under the same obligations as the website.

Open edX or Canvas for MOOC-style programs

Open edX is licensed under AGPL-3.0 and Canvas LMS is licensed under AGPL-3.0, and both fit programs with large open enrollment, continuing education or external learners. Open edX supports only its latest release, so running it means planning regular upgrades to a named release such as Verawood, and the next releases are planned for December 2026 and June 2027. Confirm which release your team will run, how learner data is stored under your privacy rules, and whether the platform's accessibility work meets your own standard.

How a university moves its department sites onto one platform

The sequence turns a scattered set of department websites into one governed Drupal estate, with each phase closing on a written output the university can approve before the next phase begins.

Inventory every department site and owner
The team lists every web property the university runs, including sites hosted by vendors, faculty pages on separate servers and abandoned microsites. For each site it records the owning department, the named editor, monthly traffic from the existing analytics, the platform and version in use, and whether the site relies on custom code or a third-party plugin. The step closes with a signed inventory that the web office and the department owners both accept, and it identifies which sites run Drupal 7, which run Drupal 10 or 11, and which run WordPress. Ask the partner to show how unmanaged sites are flagged so none are missed at cutover.
Design governance roles and approval states
Central web services, department editors, reviewers and accessibility staff are mapped to Drupal roles and permissions, scoped to the sections each department controls. The team defines the content moderation states, such as draft, accessibility review and published, and decides which content types need central sign-off, such as admissions or financial aid pages. It also sets the rules for the central theme and shared components, so departments can change content but not break the brand or accessibility patterns. The output is a written governance model and a role matrix that the university's policy owners approve.
Integrate campus SSO and test it with a pilot department
The team connects the platform to the university identity provider. Drupal's contributed SAML Authentication module (samlauth) allows the site to act as a SAML service provider, and the OpenID Connect module is an option where the campus directory uses that protocol. Confirm which protocol the identity provider supports before selecting a module. A single pilot department then signs in, receives the correct role, and publishes content through the full approval path. The step closes when the pilot department's editors, the identity team and the security office have signed off on account provisioning, deprovisioning and role mapping.
Run an accessibility baseline audit against WCAG 2.1 AA
Auditors test representative pages from each site type against WCAG 2.1 Level AA, combining automated scans with manual checks for keyboard use, focus order, form labels, color contrast and document structure. Findings are sorted by severity and by whether they come from the central theme or from department content. The output is a remediation backlog with owners, a record of the test scope and the methods used, and a list of pages that must be fixed before migration. Public universities should confirm with counsel how the ADA Title II rule applies to their institution, since the rule requires state and local government web content to meet WCAG 2.1 Level AA.
Sequence migration waves by risk
Sites are grouped into waves, with the lowest-risk sites moved first to prove the process and the highest-risk sites moved last. Drupal 7 sites go first among the Drupal estates because support ended on January 5, 2025, so they carry the most exposure. Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. They are migrated into a new site with the core Migrate modules and themes are rebuilt. The output is a wave plan that lists each site, its target theme, its data mappings and the test evidence needed to approve it. Ask the partner which sites will receive new themes and which will keep their content only.
Cut over with redirects and disclosure logs
Each site moves to the new platform with a tested redirect map that preserves search rankings and bookmarked URLs. Before cutover, the team confirms that any site holding student records or forms has its access and disclosure logging in place. FERPA requires institutions to record each request for and disclosure of personally identifiable information from education records, and to keep that record for as long as the records are kept. The cutover is accepted when the redirects return the expected responses, the analytics tags fire, the logging retention matches the university's records schedule, and the department owner signs the go-live checklist.
Hand over the platform with an update runbook
The team delivers the operating documentation to the university's web office and platform staff. The runbook covers the monthly bugfix and security release process, the test environment used before each update, rollback steps, the role matrix, the SSO configuration and the accessibility regression checks. Drupal's bugfix releases come out on the first Wednesday of each month and security releases on the third Wednesday, so the schedule must be assigned to a named owner. The step closes when university staff have run one update cycle themselves or with observed support, and the open backlog is handed to the owners named in the inventory.

Integration points and hosting pattern for a campus estate

A campus estate with hundreds of department sites connects to a small set of central systems: identity, search, calendars, forms and student records. The hosting pattern decides who controls each connection, which is where FERPA school official limits and access controls become concrete engineering decisions.

Campus identity via SAML or OpenID Connect

Editors and, where needed, authenticated visitors should sign in with the campus identity provider rather than local Drupal accounts. The contributed SAML Authentication module lets the site act as a SAML service provider, and the OpenID Connect module creates accounts on first sign-in. Confirm which protocol your identity provider supports, how group claims map to Drupal roles per department, and who owns deprovisioning when an editor leaves.

Search, calendar and directory feeds

Department sites depend on feeds from central systems: campus-wide search, event calendars, and staff directories that change often. Decide which feeds are pulled at render time and which are cached, and who maintains the field mappings when the source system changes. Ask for a documented feed contract for each source, including the owner, refresh interval and the behavior when the source is down.

Form and application submissions

Admissions, advising and financial aid forms collect personally identifiable information from students. Under FERPA, an outside contractor may act as a school official only when it performs a service the institution would otherwise use employees for, and the institution must use access controls so that school officials see only the records in which they have a legitimate educational interest. Set submission storage, role-based result views and an access log before any form goes live.

Student system integrations under institutional control

Connections to the student information system, learning management system or payment services should run under the institution's direct control, with credentials and API scopes issued to the institution rather than to a vendor's shared account. Document each data flow, the fields it carries and the retention applied on the CMS side. Ask the implementation partner to show where each integration credential is stored and how it is rotated.

Hosting in your own cloud or data center

Hosting inside the institution's cloud tenancy or data center keeps site data, editor accounts and submissions under the same controls as other campus systems. Drupal runs on Apache or Nginx with MariaDB, MySQL, PostgreSQL or SQLite as the database, so the choice should follow the team's operating skills and backup tooling. Confirm the PHP version in use against the Drupal version in the release plan, since Drupal 11 requires PHP 8.3 or later.

CDN and backup scope

A CDN in front of department sites reduces load on shared hosting, but it also caches pages that may include form state or authenticated content. Define which paths are cacheable, which are excluded, and where logs and cached copies are stored. Backups should cover the database, the file store and the configuration export for every site, and restore tests should be scheduled with named owners. Ask the partner for the restore time they have demonstrated for a single department site.

What auditors and regulators ask a university to show

This table maps each obligation a university web estate faces to the evidence an assessor expects and where it usually breaks down. Read it as a checklist for the Drupal estate, its identity layer and its contractors. DeployOpen prepares this evidence for your assessors, but it does not issue audit reports or attestations, which independent auditors and certification bodies provide.

Requirement	Evidence an assessor expects	Where it usually fails
ADA Title II (WCAG 2.1 AA)	Accessibility audit reports, remediation tickets linked to pages and templates, and a dated record of retested fixes	Audits cover the homepage only, and department sites added later are never tested
FERPA legitimate educational interest (34 CFR 99.31)	Role and permission exports per site, plus periodic access reviews signed by the data owner	Editors on department sites hold broad roles that were granted for a past project and never removed
FERPA disclosure records (34 CFR 99.32)	Logs of access to and disclosure of student records, kept for as long as the records are kept	Logs roll over on a short schedule or sit in a separate system nobody reviews
GLBA Safeguards Rule (16 CFR 314.4)	Written information security program, MFA enforcement records for every system user, and risk assessment history	MFA applies to the public login form but not to editor or API accounts
Patch and release governance	Log of core and module updates by date, with the Drupal security advisory each one addressed and test results	Security releases applied to production months later, or updates applied without a record
Processors and contractors with education records	Signed agreements showing direct institutional control, a list of parties with access, and redisclosure limits	Agencies, hosting vendors or form SaaS tools receive student data without being listed
Drupal 7 and older versions	Migration plan, end-of-support dates and any extended support contract in place for remaining sites	Legacy department sites keep running after support ended, with no owner or plan

What do universities ask before hiring an implementation partner?

What drives the cost of a university Drupal project?

The main cost drivers are the number of sites, whether older Drupal 7 sites must be migrated, how many themes must be rebuilt, the amount of accessibility remediation, and the work needed to add campus single sign-on. Drupal itself has no license fee, so the quote is for design, build, migration, testing, hosting and support. Ask each partner to price these components separately, state which are one-time and which recur each year, and list the assumptions behind the site count and content volume. A scope that names every site and its content types is far easier to compare than a single total.

Can a campus web team run a Drupal estate without outside help?

Many campuses run Drupal internally, but a multi-site estate with hundreds of department sites usually needs defined roles for platform operations, theme maintenance, security patching and accessibility testing. The question is whether the team has capacity for each of those roles during the year, including the release windows that Drupal publishes each month. Ask a partner which tasks it would hand over, which it would support under a retainer, and what documentation and training the institution would receive at handover.

How long does a Drupal 7 migration take for a university?

Duration depends on how many sites are in scope, how much content each site holds, how many custom modules and themes must be rebuilt, and how much cleanup the content needs before it moves. Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later, so each one is migrated into a new site, and themes must be rebuilt because they cannot be migrated. Ask for a timeline built from a site inventory, with a pilot migration of a representative site before the full schedule is committed.

What does the university need to provide during the project?

The work depends on three internal roles. An identity team must supply SSO configuration and test accounts, the web office must sign off on templates, navigation and governance rules, and an accessibility owner must approve remediation priorities and test results. Without named people in these roles, decisions stall and rework grows. Ask the partner for a responsibility matrix that lists each internal role, the decisions it owns, and the review points where the institution must respond.

How do FERPA and ADA Title II change a Drupal build?

FERPA affects who can see student information and how external contractors are treated. A partner that performs services the institution would otherwise use employees for may receive education records only under the institution's direct control and with redisclosure limits in place, so the contract and access model must reflect that. Institutions must also use reasonable access controls so school officials see only the records they need. ADA Title II requires state and local government web content, including public universities, to meet WCAG 2.1 Level AA, with compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts, according to the interim final rule published April 20, 2026. Confirm with counsel which dates apply to your institution.

How are Drupal 10 end of life and security releases handled after launch?

Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, so any Drupal 10 estate needs a dated move to Drupal 11 or 12 before that date. Security releases arrive on the third Wednesday of the month, and bugfix releases on the first Wednesday, so a maintenance process must test and deploy them on a predictable cycle. Ask the partner how it tests updates across all sites, who approves production deployments, how rollback works, and whether the support retainer covers Drupal major upgrades as well as patches.

Does a single-sign-on integration with campus identity need extra work?

Yes, because each site must trust the campus identity provider and map roles correctly. The contributed SAML Authentication module lets a Drupal site act as a SAML service provider, and its latest stable release supports Drupal 10.3 and later and Drupal 11. The OpenID Connect module can also authenticate users and create accounts on first sign-in. Confirm which protocol your identity provider supports, how group membership maps to editor roles, and who owns the configuration after launch.

Questions to ask a partner before a university web project

Start with multisite governance, because it decides everything else. Ask the partner how the platform models the institution: whether hundreds of department sites run as Drupal multisite or as separate installs, how a central web team provisions a new site from a shared design system, and which roles exist at the site level versus the network level. Ask for the role matrix in writing, including who can publish, who can change menus and footers, who can add a new content type, and who can grant a department editor access. Then ask how a department editor's permissions are scoped so that one department cannot edit another's pages, and how that scoping is tested before each release. A partner that cannot show this as a working configuration is describing a plan, not a platform.

Next, ask how WCAG 2.1 Level AA is tested in every release, not once at launch. The question to press is who signs off. Ask which automated scanning runs in the pipeline, which manual testing with assistive technology is performed on the shared theme and on each new component, and whether a department can publish a page that has not passed those checks. Ask for the defect log from the last release and the named institutional role that approves a release for accessibility. On identity, ask how the SAML Authentication module (samlauth, latest stable 8.x-3.14, which supports Drupal 10.3 and later and Drupal 11) or the OpenID Connect module is configured against the campus identity provider, including attribute mapping, how accounts are created on first sign-in, and how a departed staff member loses editor access in every site at once.

Then cover the migration and the evidence. If any site is still on Drupal 7, ask for the migration plan and the date it will leave support: Drupal 7 security support ended on January 5, 2025, and Drupal 6 and 7 sites cannot be upgraded in place, so themes must be rebuilt. Ask how monthly security releases are applied across the whole estate, who tests them on a staging copy first, and how long a site can stay behind. Finally, ask which records the partner will hand over for FERPA. Under 34 CFR 99.32, the institution must keep a record of each disclosure of personally identifiable information from education records, so ask whether the platform logs access to student data and how a contractor's access is limited under the institution's direct control. Confirm with your counsel which of these records the institution itself must hold.

How DeployOpen scopes and supports a university web estate

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the university's own cloud accounts, data centers or networks. For a higher education web estate, that means agreeing in writing which department sites, editor groups, SSO connections and theme components are in scope before any build starts.

How we scope

Inventory the department sites, editors, languages and shared components that the written scope will cover
Map campus SSO, role-based editing rights and central governance decisions before any build begins
Agree in writing which Drupal version, theme rebuild and Drupal 7 migration work sits inside the fixed scope

How we build

Build a multi-site Drupal configuration with a shared theme and central brand controls agreed with the university
Configure SAML or OpenID Connect sign-in for editors and document how accounts are created on first login
Test accessibility against WCAG 2.1 Level AA during build and record the findings for remediation

How we hand over

Deliver written runbooks for site provisioning, editor onboarding, theme changes and the release process
Document the accessibility test results, open defects and the plan for remediating them
Train central web staff and department editors on the workflows the university chooses to run

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, priced separately from the fixed-scope build
Apply core and contributed module security releases on a schedule agreed in the retainer
Prepare the system, controls and evidence for accessibility and privacy reviews, with auditors and regulators making the final determination