Running multi-site Drupal for many departments

A county with fifty departments, a university with a hundred programs, a state agency with regional offices. Each wants its own space on the web, with its own editors and its own look within the brand. Central IT wants one platform to patch, secure, and keep accessible. Drupal can satisfy both, but there is more than one way to build it, and the choice shapes how the platform behaves for years.

Three architectures

For most governments with many departments that each need their own URL or subdomain and editorial team, true multisite with a shared codebase and design system strikes the best balance. Where content is heavily shared across departments, one site with sections can be simpler.

What should be shared, and what should not

• Shared across all sites: the theme and design system, component library, accessibility configuration, security settings, modules and their versions, core navigation patterns, and the footer and legal pages.
• Owned by each department: its content, its editorial team, its section navigation, and within limits, its landing page layout.
• Controlled centrally: new modules, new content types, theme changes, and anything that affects every site.

Writing this split down, and building permissions to enforce it, prevents the slow drift where each department's site becomes a custom project.

Provisioning a new department site

With a mature multisite platform, a new site should come from a template, not a project plan. The template includes the install profile, default configuration, standard content types, starter pages, roles, and the connection to shared services. Provisioning then takes hours: create the database, apply the template, assign the URL and certificate, add the department's editors, and hand over.

How updates reach every site

One codebase means one code update, but every site's database still needs its updates and configuration applied. A safe rollout:

1. Update the codebase and test on a representative set of sites in staging, including the most complex ones.
2. Deploy the code, then run drush deploy against each site in sequence, with the pipeline recording success or failure per site.
3. Roll out in waves for larger changes: a few low-risk sites first, then the rest.
4. Stop and fix if any site fails, rather than pushing on.

Governance that scales

• Role-based access tied to your identity system (Active Directory, SAML, or LDAP), so department access follows staff changes automatically.
• Editorial workflows with approval steps where a department needs them.
• A request process for new features, so one department's request is built once for everyone.
• Accessibility and content standards enforced by the platform, not only by policy.
• Shared search across all department sites, so residents find the service regardless of which department owns it.

Signs the platform needs attention

• Departments requesting custom themes or modules just for their site
• Updates that take weeks because each site needs special handling
• Inconsistent navigation and design between department sites
• No one sure how many sites exist or who owns them

Plan for the end of a site's life as well as the start. Departments merge, programs close, and campaigns end. A clear process for archiving or retiring a site, with redirects to its replacement, keeps the platform tidy and avoids orphaned sites that nobody patches or updates.

How eWay runs multi-site Drupal

eWay architects Drupal multi-site platforms for 50 or more departments, each with its own URL path or subdomain and role-scoped editorial team, sharing a central design system, navigation, accessibility configuration, and security posture. New department sites are provisioned from a template in hours, not weeks. eWay integrates access with Active Directory, SAML, or LDAP, operates shared search, and rolls updates across every site through a pipeline that verifies each one. Central IT controls platform-wide changes, and departments control their own content within defined boundaries.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• The site or sites involved, and whether the issue appears on one site or many
• For a new site request: the department, desired URL, and editors to add

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: enterprise search and content scale and making Drupal government sites accessible. More on our Drupal page.