Choosing A CMS For A University Estate: What Actually Decides It

Choosing a CMS for a university is not a product decision. It is a decision about how forty publishing teams will describe a thousand courses for the next eight years, and about how many of those descriptions will still be accurate in year three.

That is why platform comparisons rarely settle it. Modern platforms have broadly converged on features. What separates them in a university estate is the content model they encourage, whether their default output is readable without JavaScript, and how well they tolerate delegated editing without a review queue.

Our August 2026 audit of 64 UK higher education websites recorded what the sector actually runs, and what those estates publish in machine readable form. The two findings together are more useful than any vendor grid.

What the sector runs

Two things stand out. The sector is concentrated: a sector specific platform leads, with one general enterprise platform and a small tail. And the second largest group is the estates whose platform cannot be identified from outside at all, which is usually a sign of a disciplined build rather than an obscure product.

Platform identity turned out to correlate weakly with outcomes. Institutions on the same platform sat at both ends of our findings, which is the argument in composable DXP programs: the platform decides very little compared with the content model and the operating discipline around it.

The criteria that actually decide it

Ranked by how much they constrain the next eight years, not by how much attention they get in a procurement questionnaire.

The first criterion is the whole decision compressed. A course is a structured record: award, mode, duration, fees, entry requirements, start dates, department. If the platform encourages editors to lay that out as a page, every course becomes a one off, and the estate can never guarantee that a fee appears in a comparable place across a thousand pages. The consequences are set out in structured data for university course pages and publishing course facts so answer engines can read them.

The second criterion is rendering. Forty five percent of audited institutions keep fees out of server rendered HTML. That is nearly always a platform or front end choice rather than an editorial one, and it removes the fact from search results, AI answers and screen reader output at once, as covered in WCAG 2.2 for university websites.

Consolidation order, if you have more than one platform

Thirteen percent of audited institutions split the course estate across more than one domain, and most run more platforms than they would choose to. Consolidation stalls in a recognizable way: pages move, the model is decided afterwards, and the new estate inherits the old shape.

Inventory first, because you cannot consolidate what nobody owns. The output of that step is not a spreadsheet of URLs, it is a list of publishing teams with a named owner and a keep, merge or retire decision against each subsite.

Then the content model, before any template work. Then templates that carry accessibility, structured data and server rendered facts as defaults, so compliance does not depend on editor behavior. Migration comes last and starts with the pages carrying applicant demand, which is the ranking argument in SEO for universities and the design argument in university website design.

What to test in a vendor demonstration

• Model one real course as a structured record, then reuse it in three places without copying it.
• View source on the result. Are fee, entry requirements and dates in the initial HTML?
• Give a departmental editor rights and try to break the template. It should not be possible.
• Change a fee once and show every page and feed that reflects the change.
• Run one page against a keyboard and a screen reader without any bespoke remediation.
• Show the redirect and retirement workflow for a page that is being consolidated away.
• Show the integration with your student record system, not a generic API description.

Any platform that passes those seven is a viable choice. The remaining differences are commercial and operational, which is the right place for them to be decided.

Cost sits in operations, not licensing

License and hosting are the visible cost, and rarely the decisive one. The recurring cost is content operations: how many people it takes to keep a thousand course records accurate through an annual fee cycle, and how much of that work the platform can carry through structure rather than diligence.

A platform that saves two hundred editor hours a year on course updates has paid for a difference in license cost several times over, and it also removes the drift that puts an out of date fee in front of an applicant.

The cost lines a platform comparison usually leaves out

Licence and implementation cost are the easy numbers, and they are rarely the ones that decide whether an estate becomes maintainable. Four lines matter more over a five year horizon, and all four are visible before a decision if you look for them.

• Editorial time per change. If a fee update touches six pages in six places, the platform is charging you every cycle. Model the annual edit volume, not the one time migration.
• Integration surface. Each connection to CRM, student records, timetabling or marketing automation has a maintenance cost. A platform that integrates through one layer costs less than one that needs a bespoke connector per system.
• Departmental escape routes. Estates fragment because a faculty could not get a page published in time. Publishing capacity and delegated permissions prevent more sprawl than governance policy does.
• Exit cost. Content modelled as structured fields moves. Content trapped in page builder layouts does not, which is why the second migration usually costs more than the first.

The practical sequence is to model the content first, then shortlist platforms against that model. A course as a set of fields with owners, sources and update frequencies is a specification any vendor can be tested against. A list of desired features is not, and it produces demos rather than decisions.

What this looked like at the University of East London

The University of East London moved off Sitecore onto Drupal on Acquia with us, and rebuilt the estate as one platform rather than a set of pages. It is the closest reference point we have for this problem at full institutional scale, 125 years of content, students from 156 countries, and five distinct audiences reading the same site for different reasons.

The decision there was a Sitecore to Drupal move with Acquia underneath, and it was made on the criteria this article argues for rather than on a feature matrix. Multiple legacy systems, outdated design frameworks and fragmented content delivery meant the platform question was really a content operations question.

What the new platform had to do, in the order it was decided:

• Reuse content as a service, with modular blocks shared across course pages, articles and campaign pages, so one edit propagates instead of being repeated.
• Automate the fields nobody wants to maintain: course data, fees, funding, deadlines.
• Integrate rather than absorb, connecting CRM enquiry data, behavioral analytics and marketing automation through one layer.
• Hand the design system to the in house team, so publishing capacity does not depend on an agency retainer.

The operational results were 99.9 percent uptime, cross platform content reuse that cut maintenance overhead, and a team that could publish without a ticket. Platform choice did not produce that; the content model and the ownership handover did. Read the University of East London case study for the full architecture.

Frequently asked questions

What is the best CMS for a university?

There is no single answer, and the audit shows why: institutions on the same platform sit at both ends of the findings. The best choice is the platform that models courses as records, renders facts server side, and lets you delegate editing safely at your scale.

Should a university build a headless architecture?

Only with the editorial and governance operation to run it. Decoupled front ends improve control over rendering and reuse, and they also move accessibility and rendering responsibility into a front end team that has to be staffed for it.

How long does a university CMS migration take?

The platform build is rarely the constraint. Inventory, ownership decisions and the content model usually take longer than the technical migration, and skipping them is what makes second migrations necessary.

Can we consolidate departmental sites onto one platform?

Yes, if each has a named owner and a decision. Consolidation fails when it is presented as a technical change rather than an agreement about who publishes what, with templates that make the agreement enforceable.

Does the CMS affect AI visibility?

Indirectly and strongly. It decides whether facts exist as structured fields and whether they reach the HTML. Answer engines quote what they can extract, so a rendering default becomes a visibility outcome.

Where to start

Before shortlisting, write down the course record: every field a course must have, with the team that owns each one. If that document is hard to produce, the platform decision is not the blocker. The sector evidence is in the UK higher education AI discoverability report, and our platform engineering work runs consolidation with the content model decided first.

Read next

The strategic frame: higher education digital strategy and composable DXP programs. The template layer: university website design, structured data for university course pages and publishing course facts so answer engines can read them. The demand side: SEO for universities and student recruitment marketing.

Working on a university estate rather than a single page? Our higher education practice page sets out how the strategy, design, engineering and marketing work runs as one team, and the UK higher education AI discoverability report holds the audit data behind this series. Also worth reading: llms.txt for universities.

For the same audit read as a marketing diagnosis, see higher education marketing: what an audit of 64 UK university websites reveals.

Two estate wide policies depend on the platform choice above: an AI crawler policy for higher education and accessibility statements that stay true.