Why I'm betting on Drupal for higher education

I have spent the last eighteen years in Drupal. Seven of those have been inside higher education — building platforms that sit between admissions and student success, publishing platforms that carry institutional voice at scale, digital archives that matter five years after launch. That focus has given me a peculiar vantage on what Drupal actually does well, and what every other platform I’ve watched die in a university context was born to fail at.

The usual case for Drupal in higher education is familiarity. Big universities run it. MIT runs it. Ohio State runs it. That is true, and it is the weakest possible reason to choose it. Familiarity is a floor, not a ceiling. If that is your argument, you will build something that performs as well as every other thing built in the same way, which is to say: poorly.

The real case for Drupal in higher education is that it is built for exactly the problems universities actually have. Not the problems they tell themselves they have. Not the problems a consultant could sell a solution for in six weeks. The actual, grinding, multi-stakeholder, every-institution-is-slightly-different problems that swallow platforms whole if a platform is not built for survival through real change.

The problem Drupal is built to solve

Every technology choice in Drupal — the concept of entities and bundles, render arrays, hooks, configuration management — solves a specific class of problem that universities hit routinely and other platforms do not anticipate. You have four hundred nodes of content. You also have six million nodes spread across eight instances and three separate Drupal versions. You need a theme that works across all of them. You also need every school within a network to have a theme that looks nothing like the others, and when a policy change happens, you need the ability to change all of them at once. You need both.

That is not the problem WordPress is solving. WordPress is built for a publication with an editor and a team of writers. Seven years in, WordPress is great. Drupal is painful. On your eighth year, when half your writers have left, the content structure has outgrown the original schema, and you need to store relationships that post-to-post just cannot express, the calculus flips hard.

It is not the problem Craft is solving. Craft is built for a small team of developers who want to move quickly and not think about permissions or workflow or what happens when you have two hundred editors who are not developers and who are not going to watch a video before they use a system they have been promised is intuitive.

Drupal is built to survive contact with an actual university. The multisite model is not a nice-to-have architecture — it is a hard-learned lesson about how institutions actually scale. The permissions system is not overengineered — it is built for the seventeen stakeholders who have actual authority over a homepage. Hooks are not a design philosophy — they are the mechanism that lets you hand a platform to the next team, and they will extend it instead of forking it.

What almost broke me on Drupal

I am not arguing that this was all there is to the decision. Drupal is also genuinely difficult to work with. The learning curve is real. The documentation has gotten better and is still sometimes wrong. Debugging a Drupal issue is a skill that takes practice, and the practice phase can last a year. Modules in the contrib ecosystem have dependencies that are wrong or outdated or solved six different ways simultaneously, and picking the right one requires experience you don’t have yet.

I spent two years on a platform where the real blocker was not Drupal itself but the assumption that hiring a small, talented team and turning them loose on Drupal would produce a platform. It didn’t. It produced a platform that worked beautifully for the first year and groaned under the weight of accumulated wrong decisions in year three. The team was capable. The Drupal itself was fine. The gap was in understanding that Drupal platforms need a different tempo of decision-making — one where the governing decisions (the ones that will be hard to undo) are made slowly, with input from the teams that will inherit them, and with a clear view of what maintenance looks like in year five.

That is not a Drupal problem. That is a problem of scaling human decision-making at an institution, which is why it surfaced in Drupal and not in WordPress. WordPress would have produced something smaller and faster and wrong in invisible ways until it suddenly wasn’t.

What changes my mind

I am genuinely curious what the failure modes are for institutions that have chosen differently. Every platform has them. WordPress at scale has them. Craft institutions are learning them now. What are the scenarios where betting on Drupal for a university platform actually breaks down — not in year three, when you realise you forgot to think about taxonomy, but in year seven, when you have done everything right and the platform starts to show seams that Drupal simply wasn’t designed to weather.

That is the test I’m watching. Because if I find an institution that built a Drupal platform with clear eyes, made good decisions, inherited a team that understood those decisions, and still ran into a Drupal-shaped wall, then I would need to revisit this.

I haven’t found that yet.