One Codebase, One Hundred Schools, One Source of Truth

If you have worked inside a higher-ed Drupal estate of more than fifty sites, the story we are about to tell will feel familiar, with varied implementations across colleges. Patchworked functionality bolted on by different teams in different years. Significant custom code dependencies that nobody now living wrote. Inconsistent user experiences across schools and departments. Editorial onboarding takes weeks for every new program. Brand guidelines in a PDF that everyone references and nobody enforces.

This is the most common shape of a research university’s Drupal platform after a decade of distributed decisions. It is not the result of bad engineering. It is the result of growth without governance, and the cure is not another framework, another vendor, or a forklift re-platform.

The cure is making the platform you already have governable.

This is the story of how we did it for one such institution.

A top-50 US research university. Approximately 25,000 students. More than 100 institutional websites, primary properties, college and school sites, departmental sites, microsites, and standalone marketing pages, spanning a decade of decisions, running across Drupal 7, 8, 9, and 10. Hosted on Acquia Cloud. Governed by a joint marketing-and-IT council. Maintained alongside a long-tenured incumbent creative agency, we were brought in to complement, not replace.

The technical debt looked like this:

• Five different content models for "faculty profile" across schools.
• Three different ways of building events (paragraphs, layout builder, and custom blocks).
• Approximately 40 forked variants of the central design framework.
• Approximately 70 contrib modules with version drift, some sites are three minor versions behind.
• Custom code accumulated across four prior agencies and two generations of in-house staff.
• Brand guidelines in a 2021 PDF, enforced informally at code review.
• Editor onboarding of three to six weeks per new school.

Acquia Site Factory was on the table. We recommended against it.

The root cause is governance, not technology:

The root cause of patchwork is not "more agencies." It is the absence of deploy-time governance gates.

In every higher-ed estate we have audited, and we have audited many, the same pattern holds.

Anything that passes code review hits production. Reviewers rotate. Standards drift. Brand guidelines that live in PDFs are not enforced. Component contracts and accessibility checks that live in CI are.

Drupal 10 is fine. Acquia Cloud is fine. Code review is fine. What’s missing in nearly every estate we see is the enforcement layer between approved and deployed. Without that layer, every well-meaning vendor, including the incumbent, eventually adds entropy. With it, the platform becomes self-cleaning: drift is rejected at the moment it tries to enter production.

We did not need to rewrite this client’s estate. We needed to install gates.

But installing gates across 100+ sites in a finite window with one delivery team is not just a technical problem. It is a throughput problem, a traceability problem, and a consistency-under-pressure problem. That is where our AI Delivery Framework came in.

A consolidation of this size, touching ~100 sites, ~70 modules, ~40 theme variants, is the kind of program that traditionally lasts eighteen to twenty-four months and depends entirely on senior engineer attention. The risk is not the engineering. The risk is everything around the engineering: surfacing the right requirements, maintaining consistency across a large team, catching the bugs at commit time instead of release time, and reporting progress in a language that a governance council can act on.

We delivered this engagement through our six-engine AI Delivery Framework. Each engine owns one stage of the SDLC. AI handles the volume. Humans make every critical decision. The whole pipeline runs on a persistent Knowledge Engine that holds codebase context, architectural decision records, business rules, and platform configuration, and learns from every sprint.

1. Discovery Engine, Turning Every Conversation into a Sprint-ready Backlog: We ingested every stakeholder artifact from the client side: interview transcripts with 30+ school and department owners, brand audits, the legacy brand guidelines PDF, accessibility VPATs, and the past three years of in-house issue tickets. AI extracted requirements, mapped dependencies, and generated a sprint-ready backlog with full traceability to the source, every ticket linked back to the conversation that prompted it. A senior PM gated every ticket before it entered the sprint. Discovery work that would have taken six weeks of workshops took six days.
2. Build Engine, AI Pair Programming with Human-gated Merges: Every developer on the team worked with an AI pair-programming assistant loaded with the Knowledge Engine’s full codebase context. The assistant flagged anti-patterns in real time, suggested reuse over rewrite, and aligned every change against the design system. Every pull request ran an AI first-pass review (correctness, standards, coverage, performance) before a senior engineer’s human gate. +55% task completion speed. −62% production bugs in the first 90 days.
3. Security Engine, Shift-left, Every Commit: SAST analysis, secrets and credentials scans, SCA dependency audits, and OWASP Top 10 checks run on every commit. AI-enhanced filtering kept the false-positive rate under 3%, against the 20–40% typical of traditional SAST. Vulnerabilities were resolved at commit time. There were no security surprises at release.
4. Test Engine, Playwright, PHPUnit, AI-generated, Self-healing: AI-generated Playwright E2E tests with self-healing selectors covered cross-browser and cross-device user journeys. AI-generated PHPUnit suites reached 85–96% branch coverage. A multisite-aware regression suite ran a full cross-component verification diff on every build. QA engineers stopped chasing regressions and ran exploratory testing on edge cases and UX instead. Test maintenance overhead reduced by 50–70%.
5. Delivery Engine, Deployment with Stakeholder Visibility Every Sprint: CI/CD deployed on QA sign-off, no manual release steps. Post-deploy monitoring tracked regressions, errors, and performance degradation. The Delivery Engine generated plain-language sprint retrospectives for the joint marketing-and-IT governance council, velocity metrics, risk log, incident summary, next-sprint recommendations, with no technical translation needed. Every retrospective fed back into the Knowledge Engine, and the next sprint started smarter than the last.
6. Knowledge Engine, The Persistent Intelligence Layer: Holds the codebase, architecture diagrams, ADRs, brand standards, accessibility policies, environment configuration, and incident history. Feeds context to every other engine. Compounds with every sprint. By month four of the engagement, the Knowledge Engine knew the estate better than any individual on the team.

The framework’s discipline matters more here than the headline numbers. AI proposes; humans gate. Every engine has a human review point. That structure is what gave the governance council confidence to approve a program of this scale on a fixed timeline. They were not being asked to trust AI. They were being asked to trust a pipeline in which AI did the volume work, and humans approved the consequential ones.

Five engines deliver the work. Drupalfit is the gate that decides whether the work is allowed to ship.

Drupalfit sits inside the CI pipeline, between the Test Engine’s green build and the Delivery Engine’s deploy. On every merge to a platform branch, Drupalfit runs four required checks:

1. WCAG 2.1 AA accessibility: Automated axe-core scans against a representative URL set per site. Failing scans block the merge.
2. Design-system Contract Tests: Every CSS color, font family, and brand token in every compiled component is checked against the design-system token allow-list. Out-of-system tokens block the merge.
3. Drupal Upgrade Readiness: Every PR runs upgrade_status and drupal-rector to score the deprecation count. Custom-code deprecations block the merge.
4. Drupal Security Advisories: drush pm:security runs on every PR. Open advisories block the merge.

Drupalfit is the answer to the question "what stops the next decade of drift?" and the answer is: a CI job, not a PDF.

The policy that lives in code review depends on which reviewer is on rotation that week. Policy that lives in CI is enforced for every merge, every contributor, every site, every time. When the consolidation went live, the client’s estate had gates. The gates are still running. The drift is still being rejected.

That is the durable outcome.

We measured five metrics across the engagement. All five are expressed as ranges and held conservative against published higher-ed benchmarks (Princeton WDS, Stanford Sites, Arizona State, NDSU, UCSF, McGill).

We did not claim a dollar figure. We did not claim an enrollment lift. We did not claim a Lighthouse score. Those metrics are unprovable without naming the institution, and we do not name our higher-ed clients. What we can claim is the operational shift: the estate stopped accumulating debt. The next 50 sites will not rebuild the patchwork that the first 100 did.

A short list, because it matters as much as the work we did:

1. We Did Not Forklift the Platform to Acquia Site Factory: The client is still on Acquia Cloud multisite, with a shared codebase and per-site databases. Site Factory is excellent for genuinely templated networks. It is the wrong forklift for a federated research university estate where every school will legitimately demand variation.
2. We Did Not Rewrite Every Custom Module: We rewrote the ones blocking D11 readiness, contributed common functionality back to drupal.org, and replaced the rest with core or contrib equivalents. 
3. We Did Not Move to a Headless or Decoupled Architecture: Drupal is rendering the front-end. There was no business case to change that. 
4. We Did Not Displace the Incumbent Creative Agency: They continued to own their brand and design. We owned platform engineering, governance-as-code, and the AI delivery layer. Long-tenured creative partners are usually doing the brand-and-design job well; what tends to be missing is the platform-engineering-and-governance layer underneath them. That is the lane we filled. 

Forklift re-platforms have killed more higher-ed marketing budgets than they have saved. We made the platform the client already had governable. That was the assignment.

Two clocks are ticking for every higher-ed Drupal estate in the United States.

The first is Drupal 10 end-of-life on December 9, 2026. Drupal 11 requires PHP 8.3 and Symfony 7, removes everything deprecated through 10.3, and obsoletes a long list of legacy modules (Actions UI, Tracker, Book, Forum, Statistics, Tour, Help Topics). Estates that wait until Q3 2026 to start their D11 readiness work will pay emergency-rate developer hours through the holidays. Estates that put upgrade_status and drupal-rector into their CI pipeline now, and treat them as a regression test, will not.

The second is DOJ Title II’s WCAG 2.1 AA compliance deadline for public entities. Public entities serving populations of 50,000 or more, which captures every public research university in the United States, must comply by April 24, 2026. Smaller entities by April 26, 2027. The technical standard is unchanged. The 2025 Drupalfit Challenge audit of 148 Drupal sites found 84.5% had at least one detectable accessibility issue. Estate-wide compliance is only achievable through deploy-time gates. A team of accessibility specialists cannot manually fix what 100+ federated content editors recreate every week.

Both clocks are forcing functions. Neither is the real reason to do this work. The real reason is sustainability; the next 50 sites in the estate should not rebuild the technical debt the last 100 did. The forcing functions just remove the option of postponing.