Modernizing a Multi-Brand Drupal Estate with AI-Assisted Engineering

LABUSA is a U.S.-based technology and consulting organization serving public-sector, nonprofit, education, healthcare, travel, and commercial markets across enterprise architecture, CRM, digital experience, cloud, systems integration, and managed IT. It also operates its own brands and digital properties, among them a travel company focused on international cultural, heritage, educational, and group experiences.

That portfolio is the origin of the estate. Each brand acquired a website; each website acquired a Drupal installation; each installation acquired a copy of the corporate theme and the deployment scripts. Over years, this produced something with the outward appearance of a platform and the internal reality of independently maintained systems that happened to look alike.

The scale of the human organization matters more than the scale of the estate. A comparatively small internal engineering and leadership team carries the entire portfolio. Administrative access is broadly held rather than tightly scoped, and the same few people recur across the whole body of work. This is a very small group operating an estate sized for a much larger one, and that asymmetry, more than any technology decision, explains what follows.

The theme was copied, not shared

Each site shipped its own duplicate, so a single accessibility fix had to be applied once per copy — and through several different build procedures, because some copies had a working asset pipeline, some had none, and one was simply broken.

Dependency management was fragile

On several sites, the standard command to add a module reliably cascaded into a site-down state; the team’s own documentation instructed staff not to run it and to copy files in by hand instead. Core versions were pinned exactly against a dependency lock that had drifted after years of manual repair, so a clean rebuild was not possible.

The platform took itself down

Every page across affected sites began failing. Drupal’s convenience cron runs maintenance inside a random visitor’s web request; under a web request’s tighter limits, a routing rebuild was killed part-way, leaving the routing table empty — and every subsequent visitor hit the same wall. The platform could not repair itself, and the failure recurred until it was fixed estate-wide.

The defects were systemic, not local

Headings jumped from level one to level five because that was how the shared theme rendered them. No page declared a main landmark. Card links labeled “Learn More” were generated by the view configuration, so no editor could fix them. A brand accent used for small text was measured at 2.76:1, whereas 4.5:1 is required. Each was one defect repeated across the estate. And much of the content was not portable at all, living inside a proprietary page builder.

Individually, the issues were manageable. Collectively, they had begun to shape what the business could deliver.

The decision was not “should we adopt AI.” It was narrower: given a small team, a growing digital estate, and a fragile toolchain, what was the most practical path to a modern, maintainable platform?

LABUSA chose to modernize the existing Drupal estate using AI-assisted engineering rather than replace the platform, consolidate the brands, or hire to scale the team. The choice preserved accumulated investment in content, integrations, and editorial process, and avoided a disruptive platform replacement.

The rationale was not formally recorded. No evaluation document, business case, or decision memo exists in the project’s record. This is the first of several places where the evidence documents an outcome but not a deliberation: the available evidence supports the result, but not a definitive explanation of leadership intent. What can be established is that the estate represented years of accumulated investment, and that the alternatives each carried costs the organization was evidently unwilling to pay.

The strategy has a shape worth stating plainly, because it is the opposite of what the market narrative predicts. Drupal remained the content and workflow spine, while AI capabilities operated around the platform rather than inside the publishing core.

The primary publishing platforms remained deterministic and did not depend on AI inference to render or deliver core content. On the evidence, this was deliberate rather than unfinished: neither primary site carries an AI module, a vector database, embeddings, retrieval-augmented generation, or semantic search, and the corporate site’s search runs on a plain keyword index.

Model calls sit at the boundary. Upstream, at build time, an agent generates SEO metadata and image alt text into review files that a human applies. Downstream, outside Drupal, separate operational systems consume submissions and generate marketing drafts. Selectively and experimentally, one customer-facing assistant was built but not broadly activated.

Pushing intelligence to the edges and keeping the publishing core boring is the platform strategy, and it turns out to be why several later choices were cheap.

The build script replaced the configuration export

Drupal can export configuration to reviewable files; this estate has never used it. Hundreds of configuration objects exist only in the database, and the export mechanism appears nowhere in the deployment chain. Rather than adopt it mid-flight, the project made the idempotent build script the configuration artifact: a program that creates fields and content types, guarded so that running it twice is safe and running it elsewhere reproduces the first result. The estate now holds a substantial library of such scripts, most of them explicitly idempotent. This was an adaptation to incomplete configuration and release practice — not a claim that it is the ideal long-term state.

The rule file replaced tribal memory

Once a defect was diagnosed, it became a constraint. The result is a growing corpus of rules, most of which document a silent failure: one that produces no error, no log, and a page that looks fine. A file edited by the wrong user becomes unreadable to the web server, and its styles vanish, while the page still returns a success status. Each rule is a defect converted into an instruction that survives the person who found it.

Verification became executable and adversarial

The editorial format ships with an automated verification harness that builds a test page, exercises every component, renders it as a real anonymous visitor, asserts against the result, and then deletes itself.

The trap AI caught

Drupal’s paragraph permissions are granted per type, so a new type is invisible to anonymous visitors by default — while rendering perfectly for an administrator, because administrators bypass access checks. An entire case study would have shipped as a blank page for every visitor, and an administrator previewing it would have seen nothing wrong. The harness caught it only because it rendered the page as an anonymous visitor rather than as its author.

The defect AI shipped, and a human caught

A callout panel rendered at 1.31:1 contrast where 4.5:1 is required. Not a poor color choice — the intended color measures 13.48:1 — but a cascade defect: a rule written earlier in the same project outranked the callout’s own color, and because the callout is a single paragraph, the rule matched the entire panel. It was reported by a person, not by the automated checks.

The response is the lesson. The team did not write a longer prompt. It built a contrast calculator that computes every color pair in the design system against the compiled stylesheet, and made a passing run a condition of shipping. Not “the AI was wrong,” but: this class of defect needs a different instrument, and the instrument must be built.

The corporate site runs recommendation rails and an adaptive hero. A reader would reasonably assume AI. They contain none. When a visitor views a page, each topic on that page has an integer counter incremented for that visitor; the recommendations are the highest-scoring topics. That is the entire mechanism. The component has no HTTP client available to it — it is architecturally incapable of calling a model.

This is a design, not a shortfall: no external dependency, no inference cost, no hallucination surface, no data egress. Interest scores never leave the first-party table. Nothing is recorded until the visitor opts in, and the consent gate fails safe — if consent is missing, unreadable, or denied, no identifier is minted, nothing is written, and the rails fall back to recent content. A visitor who declines sees a working page, not a broken one.

Whether a deterministic counter or a model is the right instrument here is a leadership and governance question rather than a technical one. The deterministic version is cheap, auditable, and privacy-preserving. A model could infer intent that a counter cannot see, at the cost of dependency, expense, and explanation. Neither is inherently superior, and the estate has not documented a position.

The customer-facing capability that is not switched on

The travel brand has an AI travel assistant, backed by a commercial language model, with rate limiting, conversation logging, and a graceful hand-off to a human specialist. It is attached to no page, and its conversation log is empty.

The capability existed, but the record did not establish whether it was intentionally paused, awaiting validation, or deprioritized — and the three imply materially different things about the organization’s posture toward customer-facing AI. This remains a leadership question rather than an analyst’s inference.

What works

Idempotency is solved per destination rather than generically: the marketing platform keys on email address and adds tags additively; the CRM keys on an identifier scoped by environment, so development and production cannot collide in a shared system; the payment handler skips if a checkout session already exists. Three systems, three different correct answers. And when a customer submits a priced quote, the contract terms are captured into the queue message — so the record reflects what the customer agreed to, even if pricing is edited later. A legal instinct expressed as an architectural one.

What is weak

The documentation asserts the queue component is deployed identically everywhere. In fact multiple implementation variants exist across the estate, the documented form count materially understates the real one, and no authoritative inventory exists. The absence is the finding. If the broker is unavailable, the publish swallows the error: the submission succeeds, the message is silently lost, and neither a lead nor a notification is produced.

And a green log does not mean delivery. Notifications for some brands do not arrive at all — one rejected by a mail tenant, one timing out — while the failure queue sits at zero throughout. The pipeline’s success signal measures processing rather than the outcome it exists to produce.

One piece of latent fragility belongs at board level. A downstream payment step depends on undocumented execution ordering inside a third-party component for the queue message to be published at all. Verification confirms the system is safe today. But nothing documents the dependency and no test asserts it, so a change upstream could break it silently — and only for paying customers.

Accountability is concentrated to an unusual degree. Administrative access is broadly held rather than tightly scoped, a small number of people hold substantial operational knowledge and approval responsibility, and the same name appears at every approval gate — including as the person who reported the defect automated verification could not see.

What is observable is not a redistribution of work among people, but a relocation of work into artifacts. Changes a developer would once have committed to a repository are now made by an idempotent script, and version control has not been the system of record for this program. Knowledge once held by whoever last touched the site now sits in a rules corpus. “Done” has moved from it renders for the person who built it to the verification harness passes, rendering as an anonymous visitor. Review has moved from code review after the fact to an approval gate before the build begins.

AI-assisted engineering did not redistribute work across a team, because there is no team of a size where redistribution is meaningful. It changed what a very small group could attempt, and it moved the scarce resource from building toward deciding and verifying. The approval gates are not ceremony; they are where the remaining human capacity is deliberately spent. That improved repeatability — but it did not eliminate key-person risk.

Whether this concentration is a deliberate operating choice or an accumulated accident is a question for leadership, and it bears directly on that risk.

What is strong

An AI Governance Policy was ratified in July 2026, owned by the chief executive, codifying five principles: human precedence over AI output; no secrets shared with models; draft-by-default for outward-facing content; cost-aware, idempotent jobs; and auditability. Critically, it was ratified from practice rather than imposed on it, which is why it is honored. AI-generated SEO copy and alt text go to review files that a human applies; the model never writes to the site. Accessibility governance is the estate’s strongest area: contrast is computed rather than eyeballed, and a passing calculation gates release.

What is weak, and material

Version control is not the system of record. The docroot repository has not tracked this program’s work, and the script library on which reproducibility depends is not under version control at all. The institutional memory is real, but unversioned.

Configuration management is not used. Configuration and content travel together in a database dump, so there is no reviewable diff of a configuration change. Auditability, which the policy requires, does not exist on this path. And the AI policy does not cover the Drupal estate at all: the largest body of AI-assisted work in the organization sits outside the policy governing it.

Secrets management is inconsistent. Some projects do this correctly — payment keys are absent from shipped configuration, and the AI tooling takes its credential from the environment. Elsewhere, credentials are embedded in source or documentation instead of being supplied by the environment. The right pattern exists inside the estate; it is simply not applied uniformly.

Privacy has no artifact. Behavioral interest data and a traveler profile containing budget band and passport status are collected, with no assessment, retention schedule, or subject-access path. And certification and compliance language appears in marketing copy without a documented link to the operating practices that would substantiate it; no externally governed process appears in the operating record.

A complete Drupal 11 production tier has been built and is parked. Production continues to run Drupal 10. Cutting over is a coordinated release, not a single technical step.

It is presented as a deployment task. It is not.

Cutting over means running production through the release path that the last several months have shown to be the binding constraint: a chain that ships the entire development state at once, moves configuration inside a database dump, has no reviewable configuration history, and sits beside a repository that has not been the system of record for this program. The parked tier improves the hygiene but keeps the identical model.

The choice is a sequencing question with real cost either way. Complete the migration now: bank a supported platform, and accept that release engineering remains the constraint. Improve the release path first: confront configuration management, version control, and deployment controls before adding a migration to the load — and accept that the parked tier idles while the older estate ages. Or take a narrower path: apply the smaller set of changes with the best ratio of risk removed to effort — bring the script library under version control, and bring secrets management to a single standard — then proceed with explicitly accepted residual risk.

There is a cheap prior question. Several indicators that would show whether this program created business value already exist and are simply not being read: consent opt-in rate, traveler-profile completion rate, lead volume by source, time from completed development to production release, deployment backlog size and age, the rate at which editors accept AI-generated recommendations unchanged, content publishing cycle time, and defect escape rate. Leadership should begin measuring the indicators that are already available before making a major platform decision. An organization deciding with no baseline is deciding in the dark by choice.

• When AI removes the constraint on building, what becomes scarce — and would you know where your own constraint moved to?
• Our personalization engine contains no AI. Is that a design or a shortfall? What would have to be true for a model to improve it?
• Part of the estate was moved to a decoupled architecture and then moved back, in production, within weeks. Failure of judgment, success of reversibility, or both — and what is the cost of a reversal whose reasoning was never recorded?
• One brand pays for declared preferences; another infers them silently. Which is more defensible? Should one organization run both?
• Version control is not this estate’s system of record; a database dump is. Indefensible, or a reasonable adaptation to a small team — and what breaks first?
• The AI governance policy was ratified from practice rather than imposed on it. Does that make it more likely to be followed, or does it merely bless what was already happening?
• A human caught the defect the automated checks missed. Where in your delivery process is the equivalent human, and what happens when that person is on leave?
• Should the estate complete the platform migration now, or repair the release path first?