Why a multisite web platform for hundreds of sites is a governance problem before it is a software choice
A university, government agency or group running or consolidating hundreds of sites usually faces the same split: central IT is accountable for security, patching and accessibility, while departments, agencies or brands publish the content. The platform choice is Drupal or WordPress, but the work that decides success is shared updates, a shared design system, a repeatable way to provision a new site, and clear limits on what each site's editors can change. Those decisions shape the architecture long before anyone compares feature lists.
Drupal core and WordPress are both free to license. Drupal core and contributed modules are GPL-2.0-or-later, and WordPress is released under GPLv2 or later, so the budget is not a license fee. The cost sits in multi-site architecture, migration from older versions, accessibility testing and remediation, hosting and CDN, and the staff or partner time needed to ship security updates across every site on a predictable schedule. Ask any prospective partner to separate those cost lines in writing, and to state which of them recur each year.
For the public-sector and education side of the Digital experience pillar, the function is central governance of many sites rather than the operation of one large site. Before choosing between a Drupal multisite, a WordPress multisite or separate installs, confirm who may create a site, which theme and components are mandatory, who approves a change to shared code, and how a single release reaches every site in one window. Those answers determine whether the platform stays maintainable at hundreds of sites, and they should be written down before the first site is built.
Which regulations and constraints shape the multisite build
This table maps each regulation to what it asks of a shared multisite platform and the architecture decision it forces. Read each row as a requirement you must design for on day one, because retrofitting per-site access, logging or testing after launch is harder across hundreds of sites. Confirm which rules apply to your institution with counsel, since applicability depends on funding, data and location.
| Regulation or constraint | What it asks for | What it means for the multisite architecture |
|---|---|---|
| FERPA school official access (34 CFR 99.31) | Contractors may act as school officials only under direct institutional control, and access must be limited to records where users have legitimate educational interests | Scope editor and service accounts per site, restrict student-data views by role, and confirm the hosting contract keeps the institution in control of records |
| FERPA access logging (34 CFR 99.32) | Record each request for and disclosure of personally identifiable information from education records, kept as long as the records are kept | Centralize audit logs across all sites, retain them on the same schedule as the records they describe, and test that logs cover form submissions and exports |
| COPPA for sites collecting data from children under 13 (16 CFR 312.2, 312.8, 312.10) | Written information security program with a designated coordinator, at least annual risk assessments, and a written retention policy with a deletion timeframe | Flag child-directed sites in the provisioning workflow, isolate their forms and databases, and apply shorter retention rules per site rather than one global setting |
| GLBA Safeguards Rule for Title IV institutions (16 CFR 314.4) | Written information security program, multi-factor authentication for anyone accessing any information system, and FTC notification within 30 days of a notification event affecting at least 500 consumers | Enforce MFA at the identity layer for all editors and administrators on every site, document the program once centrally, and build an incident path that reaches the security team within the 30-day window |
| ADA Title II web accessibility (28 CFR Part 35 Subpart H, WCAG 2.1 Level AA) | State and local government web content must 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 | Use one shared design system and component library, run an accessibility test gate in the release pipeline for every site, and keep audit results per site as evidence |
| GDPR (Regulation (EU) 2016/679) | Lawful basis, data minimization, data subject rights and transfer safeguards for personal data of people in the EU | Decide per site where form submissions and editor accounts are stored, limit third-party scripts and add-ons that send data abroad, and map which sites are in scope |
| NIS2 (Directive (EU) 2022/2555) | Risk management, incident handling and supply chain security measures for covered entities in the EU | Treat the shared platform as a single supply chain asset with central patching, access review and incident response that covers every site |
| Hosting boundary and federal controls (NIST SP 800-53) | Where federal or contractor systems are in scope, controls define access, audit, configuration and contingency expectations for the hosting boundary | Define one authorization boundary covering shared core, hosting and logging, and separate any sites outside that boundary so their controls do not blur |
Drupal multisite, WordPress multisite or separate installs: how each option behaves
Drupal multisite runs one Drupal codebase and one Drupal core for the whole estate. Shared modules, themes and configuration live in that codebase, while each site keeps its own database and its own settings. A central team applies a core or module update once and then rolls it through every site, which is the main reason this model suits large estates with a shared design system. Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later, so the platform team should plan PHP upgrades as part of the estate, not per site.
- Update effort: core and contributed module updates are applied once to the shared codebase, then tested across the estate.
- Plugin and theme sprawl: the central team controls which modules and themes exist, which limits drift but requires a governance process for new requests.
- Per-site isolation: each site has its own database, so data separation is clearer than in a shared table model, but a faulty shared change can affect many sites at once.
- Provisioning: new sites are created from a standard profile or configuration, which keeps setup consistent once the process is automated.
Check how much each site may diverge, which contributed modules are approved, and how the central team will test a shared update before it reaches every site.
WordPress multisite runs a network of sites from one WordPress installation. A network administrator manages the shared core, shared plugins and shared themes, while each site has its own set of database tables. This keeps the core update in one place, but plugins and themes are installed and activated at network level, so one plugin change can touch every site. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. Only the most recent release in the 7.1 series is actively maintained, so the network should track the latest series rather than pin an older one.
- Update effort: core updates are applied once for the network, but plugin and theme compatibility must be checked across all sites together.
- Plugin and theme sprawl: network-activated plugins affect every site, and per-site plugins are harder to govern centrally.
- Per-site isolation: sites share one codebase and one database, so isolation depends on tables and permissions, not separate environments.
- Provisioning: the network admin can add sites from the dashboard, which is quick, but template and content standards need separate enforcement.
Confirm the plugin approval process, the testing environment for network-wide changes, and whether the network will stay on the current 7.1 series release.
Separate installs give each site its own codebase, database, server or container, and its own update cycle. Isolation is the strongest of the three options, so one site can run a different module set, a different theme or a different PHP setting without affecting the others. The cost is that every site needs its own update, testing and backup work. For a few sites this is manageable. For hundreds of sites, the number of update cycles grows quickly, and security patches that must be applied everywhere become the main operational load.
- Update effort: every site receives its own core and module updates, so effort scales with the number of sites and their divergence.
- Plugin and theme sprawl: each site can carry its own plugins and themes, which increases the total number of components to patch.
- Per-site isolation: a compromise or a broken update stays within one site, which helps where sites handle different data or different regulatory scopes.
- Provisioning: each new site needs infrastructure, deployment and configuration, so automation through infrastructure-as-code becomes necessary.
Ask how the team will automate patching across all installs, and whether the isolation benefit justifies the update load for the sites in scope.
The choice depends on how much each site may diverge from the others. If most sites use one design system, one set of modules and one content model, a shared codebase keeps updates manageable. If some sites need different functionality, different data residency or a separate compliance boundary, isolation becomes more important. Many estates end up in between, with a shared core for most sites and separate installs for a small set of sensitive or independent sites. The decision should be documented before provisioning begins, because changing the model later means migrating every site.
- Shared components: the more sites share a design system and modules, the stronger the case for a single codebase.
- Regulated sites: sites handling student, patient or citizen data may need separate environments even inside a larger estate.
- Editor autonomy: per-site editors can work in any model, but the permissions model differs between shared and separate installs.
- Migration path: the chosen model determines how legacy sites on older versions are moved in.
- Governance: a written divergence policy, with an approval path for exceptions, keeps the estate from drifting.
Ask the partner to map each planned site against the divergence policy before any platform decision is made.
Which platforms fit a large multisite estate and why
A hundreds-of-sites estate is governed mainly by how sites share code, identity and editors, not by the feature list. The options below differ in how much of that sharing the platform supports out of the box, and each needs a check in your own environment before you commit.
Drupal core with a shared codebase
Drupal runs many sites from one codebase, with shared modules, themes and a single update path, and it is the option most often chosen when governance and accessibility work must be consistent across departments or agencies. Multisite support in core is limited, so most large estates use a multi-site pattern built on one codebase with separate databases and sites, managed through configuration sync. Check how each site's content types, permissions and modules diverge over time, and test every contributed module against the core version you plan to run. Contributed modules such as samlauth for SAML single sign-on and the OpenID Connect module for external identity providers are used for shared sign-in. Confirm both against your identity provider before design starts.
WordPress multisite for brochure estates
WordPress multisite lets one installation host many sites that share users, plugins and themes, which suits lighter brochure-style estates where editors already know the admin interface. The trade-off is in governance: plugin sprawl, theme drift and per-site plugin decisions become the main maintenance cost as the estate grows. Ask how the network will limit which plugins each site can activate, how updates are tested across the network before release, and how the team handles plugins that are no longer maintained. Confirm the PHP and database versions your hosting provider runs against current WordPress requirements before you plan the network.
Drupal CMS as a marketing distribution
Drupal CMS is a distribution built on Drupal core that adds recipes, site templates, the Drupal Canvas visual page builder and optional AI tools for marketing and content teams. It can speed up launching new departmental or campaign sites from a template, which matters when you have many small sites to provision. The risk is that templates and recipes become a second shared layer that must be versioned, tested and upgraded alongside core. Check whether each template fits your accessibility and brand rules before a site team adopts it, and confirm how recipe updates reach sites that are already live.
Headless options as a shared content API
Strapi, Payload and Directus can serve one content API to many front ends, which can suit estates where the same content feeds apps, kiosks and several differently built sites. This is a different architecture from a traditional multisite CMS: your teams build and maintain each front end, and accessibility, preview, editor experience and page composition become your responsibility rather than the CMS's. Strapi publishes its Enterprise Edition under a separate license for components in ee directories, and Directus uses a source-available license, so confirm the license terms for your use case. Plan separate accessibility testing and editor training for any headless build.
How a multisite rollout moves from pilot sites to the full estate
The sequence turns a set of separate sites into one governed platform, proving the shared design, build and update pipeline on a small group of sites before any wider migration or provisioning begins. Each phase closes with a named output that the next phase depends on.
Inventory every site and its owners
DeployOpen works with your web governance lead and site owners to list every site, its platform and version, traffic level, languages, integrations, forms, logins and owning team. Site owners confirm which content is live, which is retired and which pages carry regulated or legally required information. The step closes with a site inventory that records the platform, PHP and database versions in use, and a migration category for each site. You know it is done when every site has an accountable owner and a recorded category, and the governance lead has signed off the list.
Define the shared design system and accessibility baseline
Designers, front-end engineers and accessibility specialists agree on the shared components, templates, tokens and brand rules that every site inherits, and which parts individual departments may change. Accessibility requirements, such as the WCAG 2.1 Level AA target that the US Department of Justice ADA Title II rule sets for state and local government web content, are written into component acceptance criteria. The output is a component library with documented usage rules and an accessibility baseline that every component must pass before release. It is done when the library renders the pilot templates and the baseline has a named owner.
Build the multisite platform and central update pipeline
Engineers choose between a single Drupal multisite codebase or separate installs managed from one pipeline, then build the shared profile, theme, modules and configuration. Core, contributed modules and the theme move through a staging environment with automated tests before reaching production. Because Drupal core receives security releases on a published schedule and WordPress only maintains its most recent release in each series, the pipeline must be able to apply patches to every site within your own change window. The output is a working pipeline with a documented rollback path. It is done when a security patch can be promoted to every site from a single change.
Pilot with a small group of sites
A limited set of sites, chosen to represent different templates, languages, integrations and editorial teams, is launched on the shared platform. Editors use the new tools for real content, and the team measures accessibility results, page performance, form and login behavior, and the number of support tickets. Findings are logged against the inventory and the component library. The output is a pilot report that lists defects, open decisions and the changes the platform needs before wider rollout. It is done when the governance lead accepts the report and the pilot sites run through one full security update cycle.
Automate provisioning and onboard per-site editors
Provisioning is scripted so that a new site is created from a template with the approved components, default roles, analytics settings, search and form configuration, and a DNS and certificate record. Editor accounts are created through your identity provider where the platform supports it, such as SAML or OpenID Connect integration on Drupal, and each editor receives role-based permissions for their own section. Training and content standards are delivered to each team. The output is a provisioning runbook and a tested onboarding checklist. It is done when a new test site can be created from the runbook without manual configuration and its editors can sign in and publish.
Migrate sites in waves from older versions
Sites on unsupported versions move in planned waves. Drupal 6 and 7 sites cannot be updated in place to current versions, so they are rebuilt through the core migration tooling, and themes must be rebuilt because they cannot be migrated. Drupal 10 reaches end of life on December 9, 2026, so migration planning for those sites must start now, not after that date. Each wave is grouped by template, risk and owner, with redirects, content checks and accessibility retesting included. The output is a migration waves plan with a named owner, cutover checklist and rollback criteria for each wave. It is done when every site has a wave assigned and the first wave has passed its acceptance checks.
Run the estate with a defined support model
Once the sites are live, a support team handles security patching on the agreed cycle, monitors uptime and performance, reviews accessibility on new content, and answers editor questions through a defined intake route. Site owners request changes through the central pipeline, and quarterly reviews confirm the inventory is current and retired sites are removed. DeployOpen can provide this as an ongoing retainer, with responsibilities, response expectations and escalation paths written into the agreement. The output is a support runbook covering patch windows, incident handling, backups, access reviews and ownership of each site. It is done when the runbook has been exercised once and each responsibility has a named owner on both sides.
Integration points and deployment patterns that keep hundreds of sites manageable
A multisite estate stays manageable when a few shared services carry most of the weight: identity, provisioning, patching, search, caching and backups. Each card below is a decision point where one shared pattern replaces dozens of per-site configurations. Confirm early with your implementation partner exactly which of these services run inside your infrastructure and which sit with a third-party CDN or hosting provider.
Central identity for editors and visitors
Editors should sign in once through the university, agency or group identity provider, not through local accounts on each of hundreds of sites. On Drupal, the contributed SAML Authentication module (samlauth) lets a site act as a SAML service provider, and the OpenID Connect module creates accounts on first sign-in. Check that deprovisioning removes editor access on every site at once, because a leaver who keeps a local password on one forgotten department site is the most common gap. Confirm which role mappings are pushed from the identity provider and which are managed per site.
Site provisioning as code
New sites should be created from a tested template, not cloned by hand. A provisioning pipeline sets the shared theme, enabled modules, default roles, analytics tags and the content structure in one repeatable step, and records the result. Ask the partner to show how a site is created, how its configuration is exported and version-controlled, and how a site is retired without leaving orphaned domains, redirects or database tables. Provisioning is also where accessibility defaults should be locked in, so new sites do not start non-compliant.
Central update and patch pipeline
One patch cycle should reach every site in a predictable window. Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so the pipeline should stage core and contributed module updates in a test copy of the whole estate before production. WordPress maintains only the latest 7.1 release line, so any WordPress estate needs the same staging discipline. Ask how plugins and themes are pinned, who approves a rollout, and how a failed update on one site is rolled back without holding back the rest.
Shared search and forms
Hundreds of sites should not each run their own search index or form backend. A shared search service lets visitors search across departments, while site-scoped filters keep results accurate for each property. Forms raise data handling questions: submissions from admissions, grants or patient-facing pages may need to stay in a defined location and be retained under a set schedule. Confirm where submissions are stored, which sites can read them, and whether the search index holds personal data that needs the same controls as the source site.
CDN and caching boundary
A CDN and page cache sit in front of the estate, and they change what is public, what is logged and where data travels. Cache rules must differ for logged-in editors, anonymous visitors and forms, or edits will appear stale or private content will be served to the wrong audience. Shared cache purging should be scoped per site so one department's publish does not flush the whole estate. Confirm in writing which parts of the CDN and hosting path are operated by your partner, which by your cloud or data center provider, and which by a third party, because that boundary sets your evidence and incident responsibilities.
Per-site backups with restore testing
A backup that has never been restored is a hope, not a control. Each site needs its own database and file backup that can be restored alone, because a single department may lose content without the whole estate going down. Shared infrastructure should be backed up as well, including the codebase, configuration and provisioning templates. Schedule restore tests across a sample of sites on a recurring basis and record the results. Ask the partner for the recovery point and recovery time they commit to in writing for each tier of site.
What auditors and regulators ask for, and which component produces it
This table maps each record an auditor, regulator or accessibility reviewer is likely to request from a multisite estate to the component that generates it. Read it as a checklist for design decisions: if a row has no owning component in your architecture, the evidence will have to be assembled by hand. DeployOpen prepares systems, controls and evidence for these reviews, but independent auditors and certification bodies issue any audit report or certification.
| Evidence requested | Requirement it supports | Component that produces it | What to confirm before go-live |
|---|---|---|---|
| Access logs of school officials to student records | FERPA disclosure recordkeeping (34 CFR 99.32) and limits on school official access (34 CFR 99.31(a)(1)(ii)) | CMS audit log, forwarded to a central log store, plus the identity provider sign-in log | Which content types hold education records, and whether the audit log records the record ID, user and time |
| Per-site role and access evidence | Least-privilege access per department or agency site, and proof that editors only reach their own sections | CMS role and permission configuration, exported on a schedule, plus the identity provider group mapping | Whether roles are granted through groups and whether an export of effective permissions per site can be produced |
| MFA evidence for administrative access | Multi-factor authentication for anyone accessing an information system under the GLBA Safeguards Rule (16 CFR 314.4(c)(5)) | Identity provider policy and authentication logs, with SSO into the CMS admin and hosting consoles | Whether MFA is enforced at the identity provider for every admin path, including direct database and SSH access |
| Written information security program and risk assessment records | Written program and annual risk assessments for operators handling children's data (16 CFR 312.8) and the GLBA program | Governance documents maintained by the client, supported by the CI pipeline's scan reports and the risk register | Named program coordinator, assessment dates and the owner who signs off each review |
| Accessibility test reports and remediation logs | WCAG 2.1 Level AA conformance under the ADA Title II rule for state and local government web content | Automated accessibility checks in the CI pipeline, plus manual audit records and a ticket trail for each fix | Coverage of templates and shared components, and whether reports are kept per release |
| Patch-level records per site | Evidence that each site runs a supported core and module version, in line with each platform's security policy | Update tooling and the CI pipeline's version inventory, with release notes stored per deployment | How older version branches are tracked, and whether an inventory covers every site, theme and plugin |
| Backup and restore test results | Recoverability of site content and databases, shown by tested restores rather than backup job success alone | Backup tool job logs and scheduled restore test runs recorded in a runbook | Restore time and data loss targets agreed with the business, and the date of the last full restore test |
| Hosting boundary documentation | Where site data, editor accounts and form submissions are stored and processed, which the auditor needs to scope controls | Infrastructure as code definitions, network diagrams and provider data processing terms maintained by the client | Whether any third-party plugin or SaaS form tool sends data outside the approved boundary |
Questions buyers ask before running a multisite estate
How much does a multisite web platform build cost?
The license fee is zero for Drupal and WordPress, so the cost is almost entirely people and infrastructure. Most of the spend falls into design and build of the shared architecture, the shared design system, site provisioning, migration of existing sites, accessibility testing and remediation, hosting and CDN, and ongoing security updates and support. Costs rise with the number of distinct templates, the number of languages, the number of legacy sites that must move, and how many integrations each site needs. Ask any partner for a quote that lists these components separately, marks which items are one-time and which recur each year, and states what is excluded.
How long does a multisite rollout take?
The pace is set by the shared foundation, not by the number of sites. Governance decisions, the design system, the provisioning workflow and the first migration wave usually take the longest, and each later wave goes faster once the templates and mappings are reused. The timeline also depends on how many sites are on unsupported versions. Drupal 10 reaches end of life on December 9, 2026, and Drupal 7 security support ended on January 5, 2025, so sites on those lines may need migration before any new feature work. Agree on a timeline only after the site inventory and content audit are complete, and ask for it in the written scope.
What does our university or agency team need to provide?
Most delays come from missing decisions, not missing code. The client team needs an accountable product owner, a governance board that can settle disputes between departments, a site inventory with owners and content status, brand and design rules, and a list of required integrations such as campus single sign-on, analytics and forms. Accessibility responsibility must also be assigned, because the ADA Title II rule requires state and local government web content to meet WCAG 2.1 Level AA, with compliance dates of April 26, 2027 for larger entities and April 26, 2028 for smaller entities and special districts. Confirm these responsibilities in the scope before work begins.
Can a small internal team run a multisite platform?
A small team can run it if the platform is built to be operated by a few people, and if updates, provisioning and support are handled through a defined process. The team needs skills in the chosen CMS, server operations, release management and accessibility checks. Central updates are the main workload, so ask whether security releases are tested on a staging copy of the full estate before rollout. Many organizations pair a small internal team with a support retainer for upgrades, monitoring and incident response. Ask a partner exactly which tasks the retainer covers and which remain with your staff.
Is Drupal or WordPress the better choice for a large estate?
Drupal is usually the stronger fit when many sites share one structure, need granular editorial permissions by section, and require workflow controls and a consistent design system across departments. WordPress can work well for a large estate with simpler templates and a larger pool of available developers, but its multisite model and plugin ecosystem need stricter governance. Both are GPL-licensed with no paid edition of the core software. Check the current PHP and database requirements, the release cadence for each, and whether the plugins or modules you need are actively maintained before deciding.
How does Drupal 10 end of life affect our planning?
Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, so any estate still on Drupal 10 needs a migration plan that finishes before that date or a funded path to continued security coverage. Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 12 requires PHP 8.5 or later, so hosting upgrades can be part of the same project. Drupal 7 sites cannot simply be updated: they are migrated into a new site, and themes must be rebuilt. Ask any partner to show the upgrade path for each site, not only for the core.
What does a support retainer cover?
A support retainer covers ongoing work after launch, such as applying core and contributed updates, monitoring, backups, incident response, hosting maintenance and periodic testing. Its scope should be written down, including response targets, which sites and modules are covered, how new sites are provisioned, and how major version upgrades are priced. Security releases follow a published pattern: Drupal's bugfix releases come on the first Wednesday of each month and security releases on the third Wednesday, and WordPress.org fixes responsibly disclosed vulnerabilities in bugfix releases. Ask how quickly each class of update is applied to the whole estate.
Questions to put to an implementation partner before you sign
Start with the architecture question, because most later answers depend on it. Ask the partner to show, for your estate, whether a shared Drupal multisite or WordPress multisite install, or separate installs per site, fits your governance model, and what that choice does to update timing, database isolation and per-site customization. Ask how a central update is staged across the fleet, which sites are canaried first, how a failed release is rolled back for one site without touching the rest, and who signs off on that procedure. Ask what the partner will confirm in writing about the Drupal 10 move: your current inventory of sites, the target version, and a plan that completes before the December 9, 2026 end of life date. Confirm the Drupal 12 timing in the Drupal core release schedule with them, since it affects the migration plan.
Next, test how permissions and accessibility are enforced in practice. Ask which Drupal roles or WordPress capabilities are used for per-site editors, how a site owner is prevented from changing shared theme or component files, and how the partner audits role assignments each quarter. Ask how accessibility is tested in every release, not only at launch: which tools run in continuous integration, which manual checks are done with assistive technology, and what evidence is kept for each site. Ask how SSO is added, which contributed module they would use for SAML or OpenID Connect (for example, the samlauth or OpenID Connect modules for Drupal), and how they handle account provisioning and removal for editors who leave a department.
Finally, pin down the hosting boundary and the contract. Ask who holds the cloud or data center accounts, who has root access to the servers, where backups are stored, how often restores are tested, and who owns the DNS and TLS certificates. Ask what the support model covers: security release application, monitoring, and incident response hours, and which of these are in the fixed-scope agreement versus a retainer. Require the written scope to list deliverables, the acceptance criteria for each migration wave, and the exit terms, including delivery of source code, configuration and documentation if you move to another provider.
How central teams and departments split responsibilities day to day
This sequence sets out who changes what in a shared multisite estate, so that central standards stay consistent while departments publish content on their own schedules.
Assign core platform ownership to central IT
Central IT owns the Drupal or WordPress core, contributed or plugin modules, the shared design system, the hosting environment, backups and security patching. Each of these is written into a responsibility matrix that names an accountable owner and a backup owner for every component. The step is done when the matrix is signed off by the CIO or web governance lead and published to every site owner. Confirm the exact split against your own governance policy, since some institutions keep hosting with a central provider and others delegate parts of it to faculty or agency IT teams.
Give departments ownership of content and local pages
Each department or agency site has a named site owner who manages local pages, news, events, staff listings and menus within the shared structure. Editor accounts are created from predefined roles, such as author, reviewer and publisher, that limit each person to their own site or section. Departments do not change core, shared templates or global navigation. The step closes when each site has at least one named owner and one backup editor recorded in the central registry, and when role assignments match the access rules your compliance team has approved.
Route shared component changes through a change board
Any change to a shared component, global template, header, footer or design token goes to a change board that includes central IT, accessibility and representatives from a sample of participating sites. The board reviews the proposed change, its effect on every site that uses the component, and the test results. Approved changes are scheduled into a release that central IT deploys to all sites at once. The step is complete when each approved change has a recorded decision, a test report and a release note that site owners can read before deployment. Confirm the board's membership and voting rules with your own governance body.
Apply security releases centrally on a fixed cadence
Central IT tracks the core and module release announcements from the Drupal Security Team or the WordPress Security Team and applies security updates to the shared codebase in staging before production. Departments are told when a release is coming and what they need to check, but they do not apply patches themselves. Because WordPress plugins and themes can update automatically only in cases the WordPress.org API controls, plugin inventories are reviewed centrally. The step is done when every site runs the same approved version and the release record shows the date each site was updated.
Run an accessibility check before each release
Accessibility testing runs against the shared components and a sample of pages from each site before any release reaches production. Central IT or an accessibility team records the results against WCAG 2.1 Level AA, and failures in shared components block the release. Site owners fix content-level issues on their own pages within a deadline the governance policy sets. The step produces a dated test report for the release and a list of open issues per site, which the accessibility statement can reference. Confirm the testing method and reviewers with your accessibility office.
Review content freshness and ownership on a schedule
Each site owner reviews their pages on a schedule set by central governance, checking for outdated dates, broken links, orphaned pages and expired contact details. Central reporting lists sites with overdue reviews or no active editor so the governance lead can follow up. Pages with no named owner are assigned or archived. The step closes when the report shows every site with a current owner and when overdue pages are either updated or retired. The review cadence and escalation path should be agreed with the governance body and written into the operating policy.
Audit access and retire inactive accounts
Central IT reviews editor accounts against the current role matrix at the interval set by policy, removes access for people who have left, and confirms that site owners have not granted rights beyond their role. Administrator access to core and shared configuration stays limited to central IT. The step is done when the audit log records each review, each removed account and each role change, and when the record can be produced to an auditor or governance committee on request.
How DeployOpen scopes, builds and supports a multisite estate
DeployOpen plans, implements, hardens, documents and supports self-hosted Drupal or WordPress multisite platforms inside your own cloud accounts, data centers or air-gapped networks. The work starts with a written scope that defines which sites, shared components, editor roles and hosting boundaries are in and out before any build begins.
How we scope
- Inventory every site, language and domain, and agree in writing which ones join the shared platform.
- Decide with you whether Drupal multisite, WordPress multisite or separate installs fit each group of sites.
- Define the shared design system, provisioning workflow, per-site editor roles and accessibility targets as written deliverables.
How we build
- Build the shared base, theme components and provisioning automation, then test them on a pilot group of sites.
- Run accessibility and security testing against the platform and its add-ons as part of the release process.
- Configure central update pipelines so core, module and theme changes are tested on staging before reaching production sites.
How we hand over
- Deliver architecture records, runbooks for provisioning and updates, and a documented per-site editor and permission model.
- Train your platform, editorial and security staff on how to add a site, retire a site and apply a release.
- Hand over evidence files such as test reports and configuration baselines that your team and auditors can review.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build.
- Track core and contributed module release cycles so security updates and major version moves are planned, not reactive.
- Confirm with us during scoping which hosting, backup and incident response responsibilities sit with DeployOpen and which stay with your team.
