Five CMS instances, one university: what consolidation actually requires

Five sites. Three on WordPress. Two on Drupal. Different themes, different plugin stacks, different people managing each one. One security incident away from a very bad semester.

This is the scenario facing a growing number of university web directors. The instinct is always the same: consolidate everything onto one platform, reduce the maintenance surface, move on.

That instinct is correct. The execution assumptions behind it are usually wrong.

The problem is not five websites

The technology problem is real but solvable. WordPress and Drupal are both well-understood platforms with mature migration tooling. Content can be extracted, transformed, and loaded. Templates can be rebuilt. URL structures can be mapped and redirected.

The problem that actually stalls university consolidation projects is organizational. Each of those five sites exists because a college, department, or administrative unit needed autonomy. They chose their own CMS. They hired their own developer or agency. They built workflows around their specific setup. Their content editors know their system.

Proposing consolidation means proposing that five groups give up control in exchange for a promise that the new shared platform will serve them as well as the thing they built for themselves.

That is a governance conversation, not a technical one. It needs to happen before a single line of migration code gets written.

What makes mixed-CMS consolidation harder than it looks

A pure WordPress-to-WordPress or Drupal-to-Drupal consolidation carries one set of challenges. Mixed environments multiply them.

Content models do not align. WordPress and Drupal structure content differently at a fundamental level. WordPress posts and pages with ACF or custom fields do not map cleanly to Drupal's typed entity system, where content types, paragraphs, and entity references create a more granular content architecture. A Drupal node with paragraph components has no structural equivalent in a standard WordPress post. This matters for migration because the transformation layer — whether built with Drupal's Migrate API, WP-CLI exports, or custom ETL scripting — needs to account for structural mismatches, not just content transfer. Flattening rich Drupal content into WordPress, or forcing loosely structured WordPress content into Drupal's stricter model, produces results that are technically complete but editorially broken.

Version gaps compound the migration scope. Mixed-CMS environments in universities often involve sites at different platform maturity levels. An older Drupal site and a more recent WordPress installation represent different eras of CMS architecture. The consolidation project may actually be two or three migration projects happening simultaneously, each with its own upgrade path to reach a target state. The hosting layer matters too. Sites running on managed Drupal or WordPress platforms like Pantheon or Acquia Cloud have platform-specific workflows, caching configurations, and deployment pipelines. Moving off those platforms — or consolidating onto one of them — is its own workstream. Ignoring the infrastructure layer when scoping a consolidation leads to surprises late in the project when costs and timelines are hardest to adjust.

Editorial workflows diverge. The people managing a departmental WordPress site are accustomed to a specific editing experience. Moving them to Drupal's admin interface, or vice versa, without investment in editor experience design creates resistance that compounds over time. Consolidation projects can succeed technically and fail operationally because nobody budgeted for retraining or for building an editorial interface that actual content editors could use without frustration.

Plugin and module dependencies create hidden scope. Every WordPress plugin and Drupal module represents a decision someone made to solve a problem. Forms, events calendars, directory listings, accessibility overlays, SSO integrations via SAML or CAS — each one needs to be inventoried, evaluated, and either replicated on the target platform or replaced. A WordPress site using Gravity Forms and a Drupal site using Webform are solving the same problem with different architectures. The consolidation team needs to audit not just the content but the functional layer underneath it. The sites that look simplest from the outside often carry the most hidden functional complexity.

The decisions that actually matter

Three decisions shape whether a university consolidation project delivers what it promises or becomes a multi-year drag on the web team.

Platform choice has to be defensible, not tribal. Drupal has strong multi-site capabilities, granular role-based permissions, and an accessibility story that matters in higher education. Its entity and field architecture supports complex content models across distributed teams. WordPress has a larger talent pool, a lower barrier for departmental content editors, and a mature multisite installation option. The right answer depends on the institution's governance model, technical staffing depth, accessibility and compliance requirements, and how much custom functionality lives in the current sites — not on which platform the agency prefers.

Governance design precedes information architecture. Who approves content? Who can create new sections? Who owns the design system? Who decides when a department gets an exception to the shared component library? These questions feel administrative. They are architectural. The content model, permissions structure, and deployment workflow all flow from governance decisions. Getting this wrong means rebuilding the platform within two years as departments route around constraints that don't fit their needs.

Migration is a content strategy project. The consolidation moment is the only time a university will audit, restructure, and clean up content across its entire web presence. Treating migration as a lift-and-shift — running Migrate API source plugins or WP-CLI exports and loading everything into the target with minimal transformation — wastes that opportunity. Treating it as a content strategy engagement, with defined content types, defined owners, defined lifecycle rules, and a content mapping document that goes through editorial review before development begins, produces a platform that stays clean instead of re-fragmenting within a year.

What the industry pattern suggests about outcomes

The outcomes of multi-site consolidation in higher education are well-documented across the industry, even where specific engagement details remain confidential.

The pattern that emerges from publicly available case studies and conference presentations at events like DrupalCon and HighEdWeb is consistent. Institutions that complete consolidation projects typically report reduced maintenance overhead from managing fewer platform instances, a smaller security attack surface, and more consistent accessibility compliance across their web presence. The less frequently discussed outcome is editorial velocity. A consolidated platform with a component-based content model can support new departmental sites without new infrastructure — in principle, this shifts the central web team from a bottleneck to an enabler.

These outcomes are not guaranteed. They depend heavily on the governance and content strategy decisions described above. Consolidation done poorly — as a pure technical migration without organizational alignment — often reproduces the original fragmentation within a few years as departments build workarounds to compensate for a platform that does not serve their needs.

What to take from this

If you are a university web director scoping a consolidation project, the three highest-leverage actions happen before any agency engagement begins.

Build the functional dependency inventory yourself. Do not wait for an agency discovery phase to tell you what your sites actually do. Run a full plugin and module audit across every instance. Document what each one does, whether the target platform has an equivalent, and what happens to dependent workflows if it is removed or replaced. This inventory is the single most accurate predictor of actual project scope. The gap between what leadership thinks each site does and what it actually does is where budgets break.

Get governance buy-in in writing, not in principle. A verbal agreement from department heads that they support consolidation is worth very little once their content editors lose access to a familiar tool. Define the governance model in a document that specifies roles, permissions, exception processes, and escalation paths. Circulate it. Get sign-off. This is the artifact that prevents the project from stalling at 60% completion when political resistance materializes.

Separate the platform decision from the migration decision. Choose the target platform based on institutional requirements: staffing, compliance, editorial complexity, integration needs. Then scope the migration as a distinct project phase with its own timeline and budget. Bundling these two decisions together — letting the platform choice drive migration assumptions or letting migration complexity constrain the platform choice — produces compromises that serve neither goal well.

Consolidation is worth doing. Mixed-CMS university environments are expensive, risky, and increasingly difficult to keep accessible and secure. But the project only works when treated as what it is: an organizational change project with a technology component. Not the other way around.