Modernizing a Federal OIG's Drupal Platform Without Taking the Public Site Offline

How a multi-year Drupal modernization program moved a federal Office of Inspector General from end-of-life Drupal 7 to a hardened Drupal 11 architecture and a ground-up redesign aligned to a new agency identity, while sustaining publishing operations and accessibility under elevated threat conditions common to high-visibility federal sites.

Agency and system names anonymized for security. Full briefing available under mutual NDA.

9 min read

Client
A federal Office of Inspector General (anonymized)
Domain
Public-facing oversight and communications platform
Engagement
Multi-year Drupal modernization with ground-up redesign, DevSecOps, and security operations
99.99%
Public-site availability
Drupal 11
Modernized from EOL Drupal 7
Same-day
Critical-patch response SLA

The situation

A federal Office of Inspector General publishes the bulk of its oversight reporting, public notices, and stakeholder communications through a single high-visibility website. When the program began, that platform was running on aging Drupal 7 with bespoke custom modules, manual deployment habits, and limited environment separation. It was simultaneously the office's principal public-facing communications channel and a known target operating under elevated threat conditions common to high-visibility federal sites.

The program also coincided with an agency rebrand. The visible face of the office, its public website, had to be rebuilt from the ground up around a new visual identity at the same time the underlying platform was being modernized. The redesign and the replatform were not sequenced; they were a single program of work.

Drupal 7's end-of-life date set a hard floor on the timeline. The site was sustaining hundreds of thousands of visits per year, and any extended outage would directly affect the office's ability to publish to the public it serves.

ExeQut was engaged to modernize the platform, harden its security posture, and bring deployment practices in line with current federal DevSecOps expectations. The constraint was non-negotiable: do all of it without taking the public site offline and without disrupting the publishing cadence of the office's communications team.

The challenge

Several problems had to be solved in parallel, not in sequence.

  1. Replatform under load. Move an end-of-life Drupal 7 stack to a current Drupal 11 architecture without disrupting an actively published, high-visibility site.
  2. Rebuild the public face under a new identity. Deliver a ground-up redesign aligned to the agency's rebrand without forking the modernization timeline or freezing the publishing flow that was running against the legacy theme.
  3. Replace tribal deployment knowledge. Swap manual, inconsistent release habits for auditable, configuration-driven deployment that could pass federal change-control review.
  4. Defend a known target. Harden the platform against ongoing threat activity and the steady stream of critical Drupal CVEs (publicly disclosed software vulnerabilities) that follow any popular CMS.
  5. Sustain accessibility through every iteration. Hold Section 508 and WCAG conformance steady across every theme change, content migration, and configuration shift.
  6. Compress emergency response. Tighten patch governance so a critical Drupal security advisory could move from disclosure to production within the same business day.

The approach

Operating model: embedded delivery alongside federal program staff

ExeQut embedded with the federal program team rather than operating as an arms-length vendor. Engineering, content publishing, and design were treated as parallel workstreams with a shared cadence: change windows were planned around the office's publishing calendar, not the other way around. Federal program staff sat in code and configuration review, change-control was a joint exercise, and release approvals were captured in the same governance flow as the code itself.

The practical effect was that communications staff were never surprised by a deploy, and the federal program office had a continuous, evidence-grade record of what changed, when, and why.

Modernization is the security plan. Letting a Drupal stack age past end-of-life is itself the vulnerability.

Architecture: Drupal 11 on PHP, Composer, and Drush

The target was a current, supported Drupal 11 architecture, not a like-for-like rebuild of the legacy site. That meant making opinionated calls early:

  • PHP, Composer, Drush as the operational backbone. Dependency management moved from ad hoc to Composer-defined (Composer is PHP's dependency manager), with locked versions, reproducible builds, and Drush (Drupal's command-line tool) handling cache, configuration, and database operations consistently across environments.
  • Custom code re-evaluated against contrib. Bespoke Drupal 7 modules were audited individually. Anything that duplicated functionality available in maintained contrib (community-supported extensions) was retired. Anything genuinely custom was rewritten against current Drupal APIs and brought under the same testing and review process as platform code.
  • Configuration as code. Site configuration was exported to Git and treated as a first-class artifact. Environment-specific overrides were explicit. Configuration drift between dev, staging, and production was eliminated through deploy-time configuration imports.
  • Accessibility built in, not bolted on. Section 508 and WCAG conformance was treated as a continuous workstream across theme rebuilds and component changes, with checks in the review process rather than at the end.

Design system and theme: rebuilt from the ground up around the agency's new identity

The redesign was scoped as a parallel workstream to the platform modernization, not a follow-on. The agency's rebrand defined the visual identity (typography, color, layout, voice), and the front end was rebuilt against current Drupal 11 theming conventions to express it. Templates, components, and theme architecture were built from scratch rather than ported, which kept legacy markup, inline styles, and accessibility debt from following the site forward to the new platform.

Design decisions were structured through a cross-office UI/UX working group that ExeQut recommended and helped stand up at the start of the engagement. Representatives from the offices the public site serves met regularly to align on personas, communications objectives, and user flows. ExeQut provided facilitation, methodology training, and design input, while the decisions themselves stayed with the agency. The working group gave the redesign a single, federally owned decision-making body, which prevents the late-stage rework that tends to follow when a public-facing redesign is signed off only at the end.

Accessibility was folded into design review rather than treated as a separate audit. Color contrast, focus states, semantic structure, and keyboard behavior were checked alongside visual fidelity, on the principle that a Section 508 finding caught at design review costs less than the same finding caught at launch.

Content migration was choreographed against the redesign. Editorial workflows continued running against the legacy theme until the cutover, and migrated content landed in the new templates intact, without a publishing freeze.

Infrastructure: hardened hosting with layered resilience

The platform was hosted on a federally authorized managed Drupal platform, with strict environment separation across development, staging, and production. Edge protections, rate limiting, and platform-level mitigations were layered so the site could absorb sustained pressure without manual intervention from the operations team. Patch pipelines were tuned for the case that mattered most: a critical Drupal security release that needed to ship the same business day. Build caching, test gating, and approval routing were structured so vulnerability response could move through the pipeline without waiting on cold rebuilds or ad hoc sign-off chains.

Configuration that lives in tribal knowledge cannot pass audit, and it cannot move fast under fire.

Deployment: Git as source of truth, Composer artifacts promoted across environments

Git became the single source of truth. Releases moved through environments via automated pipelines triggered from version control rather than from individual workstations. Composer-built artifacts were promoted, not rebuilt, between environments, which removed an entire class of "works on stage, breaks on prod" failures. Emergency change procedures were written, rehearsed, and pre-approved so that vulnerability response did not depend on assembling the right people in the right room at the wrong hour.

The right measure of a federal modernization is not what shipped on cutover day; it is what the agency can do on its own the day after transition.

The outcome

The platform moved from legacy Drupal 7 through to a current Drupal 11 architecture, and from the legacy theme to a ground-up redesign aligned to the agency's new identity, with continuous publishing and no accessibility regressions. Throughout the engagement, the site continued to serve hundreds of thousands of annual visits and held 99.99% measured availability, including through the threat activity that the layered edge and platform protections held without manual operator intervention.

When modernization completed, ExeQut transitioned the platform back to the federal team with a hardened CI/CD pipeline, configuration-driven release management, documented patch governance, rehearsed vulnerability response procedures, and a deliberate knowledge-transfer track that walked federal engineers through the operational practices the platform now relied on. The federal team inherited a system they could run, audit, secure, and evolve themselves.

What we took from it

A few generalizable lessons for federal program managers and technology leaders running similar modernizations:

  1. Aging is the vulnerability. End-of-life CMS versions are not a maintenance problem you can defer; they are an active security exposure. Modernization should be funded and prioritized as part of the security plan, not separately from it.
  2. Configuration must live in Git, or it does not really exist. Anything held in a database, a wiki, or someone's memory cannot be audited, cannot be reproduced, and cannot move fast in an incident. Make configuration a first-class, version-controlled artifact early.
  3. Rehearse the bad day before it arrives. Emergency change procedures need to be written, walked through, and pre-approved before the next critical CVE drops. Patch velocity is a process problem more than a technology problem.
  4. Make the agency the design owner from day one. A public-facing redesign that touches multiple offices is an alignment problem before it is a design problem. A cross-office working group that owns personas, communications objectives, and user flows from the start produces design decisions that carry federal endorsement going in, not endorsement won back later through rework.
  5. Accessibility is a continuous workstream. Section 508 and WCAG conformance has to be embedded in the review process for every theme change and content migration, not retrofitted at launch.
  6. Plan the handoff from day one. A modernization is only successful if the federal team can operate, secure, and evolve the platform after transition. Document, train, and step back deliberately.

Want the unredacted briefing?

Agency, systems, architecture, vendors, and outcomes. We walk you through the full engagement under mutual NDA.

Request a private briefing โ†’