What University Drupal Projects Reveal About the Limits of Vendor Independence

Published case studies of Drupal implementations at three universities document changes in how the institutions manage their websites, but leave an important question unanswered: how easily could they change technology providers again? Projects at the University of East London, the University of Namur and Wright State University demonstrate different forms of control over publishing systems. None of their public case studies establishes the cost or practical difficulty of transferring the completed implementation to another provider.

That distinction has become relevant to a wider debate about university technology dependence. During an EDUCAUSE 2026 session on 30 September 2026, Tara Hughes, chief information officer at California State University, Monterey Bay, and Matt Hughes, senior technology strategist and network architect at the California State University Office of the Chancellor, discussed how institutions could reduce vendor dependence. They examined alternatives involving open-source software, automation and strategic partnerships. Sara Custer, editor in chief of Inside Higher Ed, revisited their arguments in an editorial column published on 22 October 2026, highlighting concerns about dependence on major technology companies and the difficulty universities face in recruiting specialist IT staff.

Custer reported that the Hugheses identified "customer capture" as a problem in which technology providers make it difficult for customers to leave or connect competing products. Their presentation drew on the Franco-German Joint Paper on Digital Sovereignty, published on 17 June 2026. Section 3.5 of that document identifies substitutability and interoperability as important characteristics of technological independence. Substitutability concerns whether institutions can change providers or technologies within reasonable financial and operational limits, while interoperability depends on modular architectures, open interfaces and documented components. The paper also calls for migration paths and technical, economic and legal exit strategies.

These are criteria drawn from a broader policy framework, not a formal certification standard for university websites. The EDUCAUSE session did not endorse Drupal or announce a shift towards open-source content management systems. However, the criteria offer a way to assess what documented Drupal implementations actually demonstrate about institutional control. Examining the three projects through platform choice, governance and technical portability reveals different dependencies that their published implementation accounts do not fully resolve.

University of East London: Changing CMS Without Removing Platform Dependencies

The University of East London provides the clearest example of how changing a CMS can alter, rather than eliminate, commercial dependencies. According to documentation published in December 2022 and a subsequent case study from June 2024, the university worked with Axelerant to replace Sitecore with Drupal and services from Acquia. The project removed Sitecore as the underlying CMS and introduced low-code publishing through Acquia Site Studio. Axelerant reported that non-technical staff could create course pages using reusable components without developing individual page layouts.

However, the university's choice of an open-source CMS core did not make the complete implementation independent of commercial software. The June 2024 case study identifies Acquia Cloud as the hosting platform and Site Studio as the page-building system. Acquia's published Site Studio Product Guide, last updated on 20 May 2025, describes a subscription-based service requiring API credentials and licensed materials. Its published terms restrict service use to Acquia Cloud Platform and agreed domains unless other arrangements are made. These are product-level conditions, not evidence of the terms in UEL's undisclosed individual contract or the agreement in force during its original migration.

The distinction matters when considering whether the university could replace Acquia without rebuilding parts of its website. Acquia provides package export tools for transferring Site Studio configuration and dependencies between environments. Its Drush export documentation describes exported configuration files that are not directly compatible with conventional Drupal configuration imports. These capabilities support movement between Site Studio environments, but do not establish that the presentation layer can be reproduced in Drupal core's Layout Builder or another page-building system without conversion or redevelopment.

UEL therefore demonstrates greater choice at the CMS-core level while retaining dependencies in hosting and page construction. Axelerant also reported providing system maintenance when its June 2024 case study was published. The sources do not establish the university's current support arrangements, total cost of ownership or contractual exit provisions. Most importantly, they do not quantify how much engineering would be required to preserve existing layouts and editorial workflows if UEL replaced Site Studio or moved to another hosting provider. Without that evidence, a reduction in overall vendor dependence cannot be measured.

University of Namur: Editorial Control and Technical Dependence

The University of Namur illustrates a different distinction between institutional governance and supplier independence. According to a September 2024 case study from WebstanZ, approximately 50 previously separate university websites were consolidated into one Drupal platform. The implementation uses the open-source Group module to maintain distinct publishing areas and permissions for faculties and institutes, while Paragraphs supports structured page composition. This arrangement gives academic units defined editorial responsibilities within a centrally managed system.

That is evidence of internal publishing governance, not necessarily independence from external technical support. Unlike UEL's commercial Site Studio services, Group and Paragraphs are distributed as open-source Drupal modules. Nevertheless, the university's shared platform incorporates institution-specific access rules and integrations with systems including Keycloak authentication, directory information and Solr search. Maintaining those connections requires technical knowledge of the complete implementation. Consolidation may simplify administration compared with managing dozens of separate websites, but it also places multiple departments within a common technical environment.

WebstanZ's own project account states that the agency trained and supported university staff responsible for working in the Drupal back office. That documents a transfer of editorial capability. It does not establish that the university's internal IT team received the infrastructure documentation, deployment procedures or specialist training required to maintain and upgrade the system independently. Nor does the case study disclose whether another agency could assume responsibility without substantial investigation or redevelopment. The higher-education staffing constraints identified by Custer make such questions relevant, but the available sources do not establish that Namur lacks those capabilities or remains dependent on WebstanZ for maintenance.

Wright State University: Migration and Portability

Wright State University presents a third problem: the engineering effort required to move institutional systems even when both the original and replacement platforms use Drupal. In a case study published in May 2026, OPTASY described migrating nine interconnected Drupal 7 websites to a Drupal 10 multisite architecture. The agency reported developing more than 50 custom migration plugins and scripts to transform legacy content structures, preserve relationships and retain existing functionality. That figure is more significant to a sovereignty assessment than the volume of content migrated, because it identifies the custom engineering required to make institutional data usable in the replacement system.

Drupal's official upgrade documentation confirms that moving from Drupal 7 to Drupal 10 requires migrating content and configuration into a new installation rather than applying a routine update. Changes in data storage and architecture mean that contributed modules, custom fields, themes and integrations may require additional migration work. Wright State's project used Drupal migration tooling and custom scripts to address those requirements. OPTASY also described the resulting framework as reusable, so the custom scripts should not automatically be characterised as technical debt or evidence of continuing vendor lock-in.

The replacement multisite architecture introduces its own maintenance considerations. Drupal's multisite documentation describes separate websites running from one shared codebase, with each site retaining its own database and configuration. Shared core and module changes therefore require coordinated compatibility testing across the affected sites, although database updates can be performed separately. The architecture can reduce duplication, but it does not remove the need to manage site-specific configurations, custom integrations and compatibility across the shared installation.

Wright State's own records provide additional evidence of how the university approached the upgrade. A Faculty Senate agenda dated 28 January 2026 stated that Computing and Telecommunications Services and University Communications and Marketing were working with a vendor to upgrade the university's Drupal CMS. It also identified email and temporary SharePoint pages as contingency arrangements if the Senate website were affected. The document confirms internal involvement and vendor-assisted upgrade activity, but does not identify the vendor, establish an actual disruption or demonstrate exclusive dependence on an outside provider.

The remaining portability question concerns what Wright State can do with the completed migration work. OPTASY reported delivering a reusable framework and working with the university's internal IT and digital services team. However, the case study does not establish whether the migration scripts, configuration procedures, automated tests and operational documentation are sufficiently complete for another team to maintain or reuse them. It also does not disclose the cost of future upgrades or transferring maintenance to another provider. The project demonstrates that open-source data access does not eliminate migration complexity, but it does not prove that the new architecture has recreated the same dependency.

What the Three University Cases Establish

Taken together, the three cases expose a limitation in the evidence normally available from implementation case studies. East London documents a move away from a proprietary CMS while retaining commercial platform services. Namur documents distributed editorial authority without establishing independent infrastructure management. Wright State documents extensive migration engineering without establishing the transferability of that engineering work. The published accounts describe project delivery and functionality, but do not provide the contractual exit costs, independent maintenance assessments or handover evidence needed to measure vendor independence.

The practical test of digital sovereignty is therefore not whether a university uses open-source software or has successfully completed a migration. It is whether the institution can change hosting and development partners, maintain its systems using available expertise, and move content and custom functionality within acceptable time and financial limits. The Franco-German framework makes those requirements explicit. Until the universities' contracts, technical documentation and operational arrangements can be examined, their Drupal implementations demonstrate specific forms of institutional control, not verified independence from technology vendors.