Application Modernization & Support

These systems calculate benefits, separate aircraft, and track materiel, and they have done it correctly for decades, which is the main reason no agency has prioritized replacing them ahead of something more urgent.

Of the eleven systems GAO ranks most critical, eight run on outdated programming languages, four depend on hardware or software the vendor no longer supports, and seven operate with known security vulnerabilities that cannot be patched without touching code nobody wants to touch.

The workforce that maintains that code is also leaving. COBOL, Assembly, MUMPS, and IDMS still sit underneath tax processing, benefits adjudication, and health care, and agencies are losing those skills faster than they can hire replacements.

GAO identified the ten systems most in need of modernization in 2019 and has tracked their progress since, reporting that three had been completed as of February 2025. Its current list has grown to eleven.

The cause GAO gives is not technical. Agencies stall because their modernization plans are incomplete, lacking firm milestones, an accurate description of the work required, and a decision about what happens to the legacy system once its replacement is running.

The Department of Veterans Affairs made three unsuccessful attempts to replace its health record between 2001 and 2018, began a fourth, and paused it in 2023. The Department of Education launched a new FAFSA system in 2023 with errors that affected roughly 30 percent of applications.

AI substantially reduces the cost of understanding an undocumented system. A model reads a codebase, maps how the components connect, and drafts tests against current behavior in a fraction of the time a team would need, and the same applies to data migration, test coverage, and the documentation that was never written.

It does not address what GAO identifies as the cause of failure. Setting milestones, deciding the disposition of the legacy system, and getting the people who use it to agree on what the replacement must do are all human problems, and none of them get shorter because the build does.

At OCH we start with the people who use the system every day, because requirements documents describe what a system was meant to do while the people operating it know what it actually does and which parts of it they have worked around for years.

We use AI to move faster through the mechanical work and keep our people on the judgment calls, and everything gets reviewed and tested the same way regardless of what produced it.

We run those models inside FedRAMP-authorized environments or inside the agency’s own accreditation boundary, so source code and data stay within the ATO perimeter. Where an agency has no AI environment in place, we build one and document it for the authorizing official, managed under ISO 42001.

We build end-to-end functionality in vertical slices rather than finishing one layer at a time, so roadblocks surface early, users can try each piece as it is built, and their feedback reaches us while there is still time to act on it.

We ship everything through a pipeline that scans, tests, and signs what it builds, with rollback triggered automatically when service levels degrade, which is what makes frequent small releases practical on systems that cannot afford an outage.