Two Websites, 140 GB, One Presidency: Inside the George H.W. Bush Presidential Library Redesign
The George H.W. Bush Presidential Library and Museum has a new website, and it is live at bush41library.gov.
Agileana designed, built, and migrated it for the National Archives and Records Administration (NARA) under NARA's Digital Design and Development Support Blanket Purchase Agreement.
The homepage opens with President Bush's own words: "Public service is a noble calling." That line turned out to be a useful north star. Because underneath the visual redesign, this project was really about access, taking 29 years of records that were technically public but practically hard to find, and putting them within reach of anyone with a browser.
Here is what the work actually involved.
The problem: one library, three web addresses, two technology stacks
Before launch, a researcher looking for Bush 41 material had to know which of three sites to visit.
The public-facing library and museum site, built on .NET Web Forms with a SQL Server backend. Its content was spread across separate databases for events, news, blog pages, and exhibits — with roughly twenty additional pages hardcoded outside the CMS entirely. Images lived in S3.
Another site held the archival heart of the collection: finding aids, the Presidential Daily Diary, textual records. It was hosted at Texas A&M University, written in PHP against a MariaDB database, and it used no content management system at all. Roughly 95 GB of templated pages and dynamic output driven straight from the database.
And yet another site was a NARA-hosted splash page on AWS whose main job was redirecting visitors to the other two.
Together the legacy footprint came to approximately 140 GB of web files. Two different languages, two different databases, two different hosting providers, zero shared editorial workflow, and Library staff who could not update most of it without help.
The goal was a single Drupal 10 website on a .gov domain that Library staff could run themselves.
Baseline before beauty
The first deliverable was not a design comp. It was a spreadsheet.
Before touching anything, we built a baseline assessment of both legacy sites: every page, every broken link, every accessibility error. That baseline became the acceptance standard for the entire project — the new site had to have equal or fewer broken links and accessibility defects than what it replaced.
This is an underrated move on any migration. A baseline turns "did the redesign break anything?" from an argument into a diff. It also protects the vendor: it draws a clear line around pre-existing problems in legacy binaries — PDFs, audio, video — that were never in scope to remediate.
Research first, then three directions
NARA asked for audience research before design, and the sequencing mattered.
We ran user experience research with two distinct groups whose needs pull in different directions:
- Library staff — the web content editors and content creators who would live in the CMS every day. Their pain was publishing friction.
- Public audiences — museum visitors, educators, and academic researchers. A visitor planning a Saturday trip and a researcher hunting a FOIA case file want almost nothing in common from a homepage.
Comparative analysis, card sorting, and tree testing shaped the information architecture. Analytics from the legacy sites showed what people were actually failing to find. From that research we presented three design and UX directions, plus a recommended sitemap, before development began.
The resulting navigation reflects the split we found: The Bushes, Research, Visit, Exhibits, Education, Events. A visitor's path and a researcher's path diverge at the top level instead of competing for the same real estate.
A USWDS theme, and Gutenberg for the people who have to use it
The front end is a custom Drupal theme built on the latest U.S. Web Design System — USWDS typography, color, and UI components, with NARA's visual identity header delivered through Google Tag Manager.
Editing is where the durable value sits. The site runs the Gutenberg editor in Drupal 10 on top of NARA's library of custom, reusable Gutenberg blocks and modules: interactive timelines, virtual exhibits, audio-visual galleries, dynamic finding aids, responsive accordions, cards, summary boxes, tables of contents, enhanced tables, data visualization, FAQs.
Because these are NARA's shared components rather than one-off custom work, every improvement we made travels. A block enhanced for the Bush Library is a block the Carter, Ford, and Reagan library teams can use. We extended several of them — including improving Gutenberg's link editing tool to search media titles rather than only node titles, and to emit clean path aliases instead of node/id references.
The practical outcome: Library staff build and update complex pages without filing a ticket.
Consolidating 140 GB into one Drupal site
We built a Drupal migration module to move content from both legacy platforms into a single Drupal 10 site. The migration had to do more than move rows.
- Content types were modeled to match the legacy data structures, reusing standard NARA and GSA patterns like
eventsandarticleswherever possible rather than inventing new ones. - Media handling brought images, PDFs, and other binaries into Drupal media types with title, category, and tag metadata, and preserved the original file structure using a taxonomy tree — not Drupal's default date-based directories. Archivists organize by provenance, not by upload month.
- Reference rewriting updated every inline image, PDF, and document reference in migrated HTML to point at the new media objects, while stripping inline styles and legacy cruft.
- Redirects were generated at every old location so existing links, bookmarks, and citations keep resolving. For a research institution, link rot is a genuine scholarly harm, not a housekeeping issue.
- A migration report documented every page with its original and new URL — an auditable record of what moved where.
Live integration with the National Archives Catalog
This is the part of the build that changes how the site behaves over time.
Rather than copying archival descriptions into Drupal where they would immediately begin to drift, the site pulls from the National Archives Catalog API. Finding aids sync from the Catalog at the series, file unit, and item level, preserving the original hierarchical order and aggregating descriptive records into finding aids by FOIA number. When new content is published to the Catalog, the site picks it up.
The same approach powers the Daily Record — the Presidential Daily Diary, Presidential Daily Files, and Photo Contact Sheets — presented in a calendar and keyword-searchable view modeled on the Ford Library's Digital Research Room. Each entry links to its authoritative Catalog record.
We also built a Catalog Image media type and Gutenberg block, so editors can search the Catalog by NAID or keyword and embed a remote image with its real title, identifier, and description, instead of downloading and re-uploading a duplicate.
One record, one source of truth, many places it can appear. That is the difference between a website about an archive and a website connected to one.
Search that a researcher can actually use
The global site search runs on OpenSearch, indexing page nodes and the text inside attached binary documents.
Search on the Digital Research Room is faceted the way an archivist thinks: filter by level of description (collection, series, file unit, item, FOIA), by record type (textual records, photographs, moving images, sound recordings, artifacts, data files), by page type (finding aid, gallery), by Presidential Daily type, and by whether material is available online or on site only.
It supports boolean and exact-phrase queries, highlights matched keywords in snippets, marks result types with icons, and supports "Best Bets" so staff can pin authoritative answers to common searches. Editors can also drop a configurable search block onto any page with pre-set filters — a "search only this collection" widget, built without a developer.
A scheduling tool built for how the research room really works
Booking a research visit used to be a form-and-email exchange. We built a custom Drupal module that handles the whole workflow.
Researchers pick from four-hour morning and afternoon blocks on a calendar, request as many slots as they need, and submit a researcher application with a PDF upload. Configurable rules enforce the real-world constraints — how far ahead the calendar opens, and a cutoff on last-minute requests. Researchers who already hold a researcher card number skip the application entirely.
On the staff side, Library personnel set the number of available seats per block, review pending and approved requests in one place, approve or decline with a comment, and push confirmed appointments to their calendar. Confirmation email text is editable in Drupal, so staff adjust their own messaging.
Accessibility as a pass/fail condition
The site was built to Section 508 and WCAG 2.0 AA, using USWDS components that carry accessibility semantics by default rather than bolting on remediation at the end. Compliance was tested throughout, documented in periodic reviews, and delivered as a formal 508/accessibility report alongside a broken-link report at the close of development — measured against that opening baseline.
Alongside it: HTTPS throughout with no mixed content, path aliases rather than node IDs, no hardcoded domains or protocols in internal links, input validation with logging and rejection of injection attempts, LDAP authentication, least-privilege user roles and content workflows, a two-second page load target, and a multi-server configuration behind Varnish and CloudFront. Everything in Git, with NARA holding access to the repository from day one.
Handoff was part of the build
A site staff cannot maintain is a site that decays. Delivery included recorded virtual training for Library web editors covering Drupal 10, Gutenberg, and every installed module, plus written user guides added directly into NARA's nara_help module — documentation that lives inside the CMS, at the moment of need, rather than in a PDF nobody can find. A 90-day post-launch support period followed final deployment.
Why this project is worth talking about
Presidential libraries occupy an unusual position. They are federal institutions, museums, archives, and educational programs at once, serving school groups and academic researchers from the same homepage. And they hold material that belongs, in NARA's own framing, to the American people.
Getting that material online is not a marketing exercise. It is the mission.
Three things from this build generalize to most federal web modernization work:
- Baseline before you redesign. You cannot prove improvement you did not measure.
- Integrate rather than duplicate. Every copied record is a future inconsistency. APIs beat imports wherever an authoritative source exists.
- Optimize for the editors. The public sees the launch. Staff live with the CMS for the next decade, and their ability to publish is what determines whether the site is still good in year three.
Agileana is a service-disabled veteran-owned small business building Drupal websites for federal agencies and mission-driven organizations. We hold NARA's Digital Design and Development Support BPA, GSA MAS, NASA SEWP VI, the DOT WA3 BPA, and a U.S. Courts BPA.
If your agency is facing a consolidation, a Drupal migration, or an accessibility gap you already know about, let's talk.
