How We Modernized a Federal Education Clearinghouse for Multilingual, Mobile-First Audiences in 6 Months

The situation

The Clearinghouse is the federal government's primary information hub for the educators, families, and administrators who serve English learners. Its public-facing platform was an aging Drupal site that had become difficult to maintain and increasingly out of step with modern web standards and federal accessibility requirements.

The deeper problem was structural rather than technical. The site itself was English-only. The actual translated material, which is precisely what the Clearinghouse's audiences most need, lived only as downloadable PDFs in a handful of languages. Non-English-speaking families and educators had to know what to search for, find the right PDF, download it, and read it outside the experience of the website. None of that content was searchable, navigable, linkable, indexable, or readable on a phone in any meaningful way.

There was also no mobile application, despite the fact that the audiences who most rely on this content (parents, families, classroom educators) are heavily mobile-first.

A program whose mission is to reach multilingual, mobile-first audiences was publishing its translated content as English-page-linked PDFs. The platform was not failing because of bugs. It was failing because of architecture.

The Clearinghouse needed a coordinated modernization: a current Drupal foundation, true multilingual web functionality, the long-trapped translated content liberated from PDFs into structured Drupal content, and a mobile experience built on the same backbone.

The challenge

The work resolved into four parallel problems that had to be solved at once, not sequentially:

1. Aging Drupal foundation. The legacy version was no longer comfortably supported, accessibility was inconsistent, and years of accumulated technical debt made even routine editorial work expensive.
2. English-only experience over multilingual content. The CMS had no first-class concept of language. Translated material existed, but only as files, not as content.
3. A PDF-locked resource library. The most valuable, most-translated assets were unsearchable, unlinkable, and effectively invisible to assistive technology and to mobile users.
4. No mobile presence at all. The mobile-first audiences the Clearinghouse exists to serve had no app, and any future app would need to feed from the same content the website used, not a parallel system.

A modernization that solved any one of these in isolation would have left the others worse off. The mandate was to solve them on a single platform, in a single delivery cycle, under federal hosting and security constraints.

The approach

We organized the work as a coordinated four-track delivery on a shared Drupal foundation, with the mobile application designed in from day one rather than treated as a downstream phase.

The operating model

A small senior team carried the work end to end: a Drupal architect owning the platform and content model, a mobile developer building the React Native application, a UI/UX designer leading the redesign and the design system, and a product owner driving prioritization and stakeholder alignment with the federal program office. Cadence was tight: weekly working sessions with the program office, continuous demos against real content, and decisions documented as they were made so the eventual transition package would not need to be reconstructed at the end.

Drupal CMS migration, scripted and repeatable

We migrated the Clearinghouse from its legacy Drupal version to a current, fully supported release. The migration was scripted and repeatable rather than manual, so future version upgrades can be executed by any inheriting team without specialized institutional knowledge. Content types, taxonomies, media, and editorial workflows were rationalized during the migration rather than carried forward as-is, eliminating years of accumulated technical debt. Section 508 accessibility was enforced at the theme and component level, not bolted on afterward.

Scripted migrations are a transition obligation, not a nice-to-have. Federal programs change contractors. The migration that ran once should be runnable again by whoever inherits the platform.

Multilingual functionality, built in from the start

We designed the new Drupal architecture around multilingual delivery as a first-class capability, not an add-on. Translation workflows, language-aware URLs, language switching, and content fallback behavior were defined at the platform level. Every piece of content, current and future, can now be authored, translated, and served in multiple languages through a single editorial experience.

This is the change that makes everything else compound. Once language is a property of content rather than a property of files, the website, the mobile app, search engines, and assistive technology all inherit it for free.

PDF resource digitization into structured content

We took the translated resource library that had been locked inside PDFs and digitized it into Drupal as structured, multilingual content. Each translated resource is now a first-class Drupal entity rather than a downloadable file, which means it is searchable, navigable, internally linkable, indexable by search engines, accessible to assistive technologies, and, critically, readable as a normal webpage on any device or in the mobile app. The original PDFs remain available where they are required by program policy or user expectation, but they are no longer the only path to the information.

Mobile application on the same Drupal backbone

We designed and built a native mobile application in React Native, targeting both iOS and Android, that uses the modernized Drupal site as its content and services backend through a decoupled JSON:API layer. Because the multilingual model and the digitized resources both live in Drupal, the mobile app inherits all of it automatically. The Clearinghouse publishes once, in any language, and the content flows to both the website and the mobile app without duplicate authoring.

One CMS publish, three channels (web, iOS, Android), in every supported language. That fan-out is the point.

Web experience redesign

We restructured information architecture around the audiences the Clearinghouse actually serves (educators, families, state and local administrators, researchers) rather than around the issuing office's internal organizational structure. The visual design system was rebuilt as reusable Drupal components so editors can publish new pages, campaigns, and resources without engineering involvement.

Deployment and release: CI/CD all the way to the store

Every artifact in the engagement shipped through automated CI/CD pipelines, including the mobile apps. Drupal builds, database updates, configuration imports, and infrastructure changes all flowed through versioned pipelines into the AWS environments, with automated test, lint, and security scan gates before any change reached production.

The mobile pipelines went further. On every change, they built signed iOS and Android binaries, ran the test suites, distributed TestFlight builds for iOS (with the equivalent internal testing track on Android) so program stakeholders could review the actual application on a real device, and produced submission-ready artifacts that flowed into the App Store and Google Play through the same pipeline. By the end of the engagement, a release was no longer an engineering event. The program owners' workflow was: review the candidate build, approve, and the pipeline carried it the rest of the way to the store.

This matters more in federal delivery than in commercial work. Audit evidence, segregation of duties, deployment approvals, and reproducibility are not nice-to-haves under an ATO regime; they are part of the control set. Pushing every channel through the same pipelined, evidence-producing path is how those controls stop being a release-day burden and start being a byproduct of normal work.

AWS hosting and the security stack

The platform runs on AWS, with EC2 as the primary compute substrate. The typical service footprint:

• Application Load Balancing in front of EC2
• RDS for the database tier
• S3 for object storage
• CloudFront as the public content delivery network
• AWS WAF and Shield for edge protection
• GuardDuty and Inspector for threat detection and vulnerability scanning
• AWS Config and CloudTrail for configuration and audit telemetry
• CloudWatch for monitoring and centralized logging
• IAM and KMS for identity and key management
• Secrets Manager for credentials
• Systems Manager for patch and inventory operations

The combination maps cleanly to the NIST 800-53 control families that federal assessors expect to see, which keeps the ATO conversation focused on evidence rather than on architecture debates.

The outcome

The engagement produced one consolidated platform, not a stack of disconnected upgrades:

• A migration to a current, fully supported Drupal version, with a scripted, repeatable upgrade path documented for any future contractor or in-house team.
• A true multilingual web platform, with translation as a first-class capability of the CMS rather than a content workaround.
• A translated resource library liberated from PDFs into structured, searchable, accessible Drupal content readable on any device.
• A net-new React Native mobile application on iOS and Android, extending the Clearinghouse's reach to mobile-first educators and families.
• A unified content publishing model: one Drupal authoring experience now drives the website and the mobile app across all supported languages.
• End-to-end CI/CD across web and mobile, with mobile releases automated all the way through TestFlight and into the App Store and Google Play, gated on a single program-owner approval.
• An AWS deployment on a typical federal-grade stack: EC2, ALB, RDS, S3, CloudFront, WAF, Shield, GuardDuty, Inspector, Config, CloudTrail, CloudWatch, IAM, KMS, Secrets Manager, and Systems Manager, mapped cleanly to the NIST 800-53 control families assessors expect to see.

The estimated five-year ROI of $2M to $4M is benchmark-derived from comparable federal CMS modernizations and reflects three compounding effects: avoided platform rework as the legacy stack would otherwise have continued to age, eliminated duplicate authoring across PDF and web channels, and (most importantly) materially expanded program reach to the multilingual, mobile-first audiences the office exists to serve. The figure is benchmark-derived rather than engagement-measured.

What we took from it

A few patterns from this engagement generalize to most federal modernization work:

1. Treat multilingual as a platform capability, not a content task. If translation is added at the content layer, it stays at the content layer, and every channel after the website (mobile, search, assistive tech, partner integrations) inherits the limitation. Putting language at the platform layer is what lets it compound.
2. PDFs are not accessibility, and they are not multilingual delivery. Federal teams often discharge translation and accessibility obligations by attaching translated PDFs to an English page. That choice is worse than it looks: PDFs are not reliably searchable, not reliably indexable, often not screen-reader friendly, and effectively unreadable on a phone. Structured content in the CMS is the standard worth holding to.
3. Decoupled architecture pays for itself the first time a channel is added. Once Drupal exposes a stable JSON:API surface, the next channel (mobile, in this case) is build-the-client work, not rebuild-the-platform work. The investment shows up the second time, the third time, and on every transition after that.
4. Automate the entire delivery path as a transition asset, not just for velocity. Scripted migrations, infrastructure as code, and CI/CD pipelines that carry mobile builds all the way through TestFlight and into the App Store and Google Play are how a federal program changes contractors without losing operational ground. By the time the engagement ends, releasing a new version should be a program-owner approval, not an engineering project.
5. Audience-led information architecture beats org-chart information architecture. Restructuring the site around educators, families, administrators, and researchers, rather than around the issuing office's internal structure, consistently outperforms on findability, on accessibility, and on the metrics federal program offices actually report against.