Federal Legacy IT Modernization With AI: Evidence for the ATO
Federal legacy IT modernization with AI must produce evidence assessors can review, keep humans in approval, and run in disconnected, classified environments.
Federal agencies do not lack reasons to modernize legacy systems. They lack a way to modernize that an authorizing official can sign off on. Rewriting a mission system is only half the problem; the other half is proving, to an assessor, that the new system does what the old one did and nothing it should not.
AI changes the economics of the first half. Whether it helps with the second half depends entirely on how it is used.
The scale of the federal legacy IT problem
The Government Accountability Office has reported for years that the federal government spends the large majority of its IT budget, roughly 80 percent, on operating and maintaining existing systems rather than developing new capability. GAO has also identified specific critical federal legacy systems most in need of modernization, many running on outdated languages such as COBOL, on hardware or software past vendor support, or with known security weaknesses. Management of IT acquisitions and operations has been a long-standing entry on GAO’s High-Risk List.
The pattern behind those reports is familiar to anyone who has run a program office. Operating costs rise as systems age. Modernization plans slip. Security risk accumulates in components no one can patch safely.
Funding mechanisms: the MGT Act and the Technology Modernization Fund
Congress responded with the Modernizing Government Technology (MGT) Act of 2017, which established the Technology Modernization Fund and authorized agencies to create IT working capital funds. The TMF lets agencies propose modernization projects to a board and receive incremental funding, generally with expectations of repayment and demonstrated progress.
Funding helps. It does not remove the reasons federal modernization is harder than commercial modernization.
Why government COBOL modernization is harder than it looks
Authority to operate is a gate, not a paperwork step
Every federal system operates under an authorization decision made through the NIST Risk Management Framework, described in NIST SP 800-37. A modernized system is a changed system. Depending on the scope, it may need a significant change review or a new authorization, with control assessments and evidence to match. A modernization approach that produces working code but no evidence has only moved the bottleneck.
Behavior is the specification, and the authors have retired
Many legacy mission systems encode decades of policy, statute, and edge-case handling directly in code. The engineers who understood why a particular calculation rounds the way it does have often retired. Workforce attrition turns the codebase into the only authoritative record of what the system does, which makes a rewrite from documentation a rewrite from an incomplete copy.
Mission systems cannot go down
Benefits payments, logistics, personnel, and financial systems have no maintenance window long enough for a big-bang cutover. Modernization has to be incremental, reversible, and verifiable at each step.
Cloud LLM APIs are not always an option
Classified, air-gapped, and otherwise disconnected environments cannot send source code to a commercial model endpoint. Even in unclassified environments, source code for mission systems may be controlled information that cannot leave an accredited boundary. Any AI-assisted modernization approach for government has to work with models and tooling that run inside that boundary.
AI for government software modernization: what it should and should not do
Used carefully, AI accelerates the parts of modernization that consume the most expert time:
- Code comprehension. Explaining unfamiliar COBOL, PL/I, or legacy Java and .NET idioms to engineers who did not write them.
- Drafting transformations. Proposing idiom and API updates as reviewable diffs.
- Generating tests. Proposing characterization tests whose expected outputs are captured by running the legacy system.
What AI should not do is decide on its own that a change preserves behavior, or commit changes without review. In a federal context, human-in-the-loop approval is not only engineering prudence. It is a governance requirement: a named individual accountable for each change is what configuration management and change control expect.
Evidence-backed modernization as an accreditation asset
The most useful reframing for program offices is this: the artifacts produced during a disciplined modernization are the same artifacts an assessor wants to see. If they are produced deliberately, they reduce authorization risk instead of adding to it.
| Modernization artifact | What it gives the assessor |
|---|---|
| Behavior map of entry points, contracts, and side effects | A traceable description of what the system does, anchored to source |
| Must-preserve path inventory | A clear statement of which behaviors are protected and why |
| Characterization and differential test results | Evidence that modernized behavior matches legacy behavior |
| Static analysis results per change | Evidence that changes did not introduce new weaknesses |
| Gate results with human approval records | A change-control trail with accountable reviewers |
This is where AI-assisted modernization and continuous assurance meet. Evidence produced per change can be correlated against controls, so that a claim like “the change was tested and reviewed” traces to the specific test run and the specific approval.
A practical sequence for modernizing legacy systems under an ATO
- Engage the authorizing official and assessors early. Agree on what evidence a modernized component must carry and how changes will be classified.
- Build the behavior map first. Extract entry points, contracts, side effects, and must-preserve paths from the code, with file and line evidence.
- Pin behavior with characterization tests captured from the running legacy system.
- Choose one bounded component and migrate it incrementally behind a routing layer (the strangler fig pattern), keeping the legacy path available for rollback.
- Gate every change on compilation, tests, differential behavior, and static analysis, followed by human approval.
- Package the evidence with each increment so it can feed the continuous monitoring and change-review processes already in place.
- Repeat, retiring legacy paths only when the new path has a verified record.
Modernization is also the moment to fix cryptography
A legacy system under active modernization is the cheapest place to replace outdated cryptography. Hard-coded algorithms, embedded libraries, and protocol assumptions will be touched anyway, and federal post-quantum migration requirements make the timing hard to ignore. Treating cryptographic inventory as part of the behavior map, and cryptographic replacement as a gated change like any other, avoids reopening the same system a second time. We cover the policy side in federal PQC mandates.
How QuantumWorks approaches federal legacy modernization
PRISM generates a Behavior Specification Graph from a codebase: a typed, evidence-anchored map of entry points, core behavior, dependencies, outputs, and risk signals, where every node points to file, line, and source snippet. Proposed behavior-preserving transformations pass compile, test, differential behavior, and static analysis gates, and none is committed without human approval. CAM is designed to turn security evidence into a continuously verifiable model that links controls to the technical evidence behind them, including portable signed evidence manifests and deterministic offline verification for disconnected environments. Together they reflect how we think about software intelligence and cyber assurance for government programs: modernization that leaves an evidence trail an assessor can follow.