CERN, GovCMS, and Stanford Set Different Limits on Drupal Customisation

The Drupal services documented by CERN, GovCMS, and Stanford Sites place different limits on who may extend the platform and who must maintain those changes. CERN separates central and site-owner responsibility, GovCMS uses service tiers, and Stanford restricts module installation to its central team. Together, the models show that enterprise Drupal governance depends on making support boundaries explicit before customisation becomes routine.

That distinction matters because Drupal’s flexibility can distribute responsibility faster than an organisation defines it. At scale, the operational question is not only whether a module or custom feature works, but who tests it against core updates, documents it, and retires it when it leaves the supported baseline. A platform migration may change the software, but it does not remove the need for those decisions.

CERN’s infrastructure documentation assigns infrastructure to the IT Drupal Infrastructure Team and official modules and themes to the Web Team. Drupal core and CERN-official projects are updated centrally through the CERN Drupal Distribution. Customised or locally installed modules remain the responsibility of individual website owners, including continued compatibility with centrally applied core updates.

CERN’s later decision to adopt WordPress followed an extensive review requested and overseen by its Web Governance Board. CERN says increasing complexity and maintenance demands prompted the review, while its WordPress roadmap also cites accessibility, responsiveness, and workflow efficiency. The organisation’s explanation therefore combines platform concerns with the operational demands of supporting a large web service.

GovCMS formalises responsibility through Software as a Service and Platform as a Service offerings. Its SaaS service includes web protection, security accreditation, Drupal security updates, and application and infrastructure maintenance, while PaaS customers retain responsibility for the application layer and website security. The GovCMS glossary also says SaaS uses a controlled distribution, whereas PaaS permits a wider set of modules and leaves application maintenance and support to the customer.

Stanford Sites applies a more restrictive extension model while retaining distributed responsibility for individual websites. Its included modules documentation says site owners cannot install modules and may instead submit recommendations to Stanford Web Services. Its site ownership documentation requires annual identification of a site owner, primary site manager, and accessibility contact for access, renewal, retirement, communications, and reporting.

The three services draw their boundaries differently. CERN divides responsibility between its central distribution and owner-maintained customisation, GovCMS ties responsibility to the selected service tier, and Stanford keeps module selection under central control while naming accountable contacts for each site. In each model, greater freedom to diverge from the supported baseline brings a clearer maintenance obligation.

The Joshi Consultancy Services blog post that prompted this comparison argues that Drupal’s flexibility becomes a liability when organisations lack architectural governance, documentation, and upgrade discipline. It also argues that migration cannot correct weak operating practices on its own. Those points align with the institutional examples, but the post’s warning against a “module-first” approach requires qualification.

Module choice alone does not establish technical debt. Drupal.org’s security advisory policy distinguishes covered stable contributed projects from unsupported projects and development releases. A maintained contributed module with security coverage and a known upgrade path can present less operational risk than bespoke code with no long-term owner. The relevant governance test is who selected the extension, who monitors it, and who is responsible for replacing it.

For enterprise Drupal teams, platform choice cannot replace operating discipline. Large organisations still need to define where customisation is permitted, who maintains it, how upgrades are tested, and when local variation must return to the supported baseline. Drupal’s flexibility remains manageable when those responsibilities are visible, enforceable, and assigned before exceptions accumulate.