Why most efforts stall and what works

Federal legacy modernization is not a new problem. Agencies have been talking about aging systems, outdated languages, brittle integrations, cybersecurity exposure, and rising maintenance costs for years. What is different now is that modernization is becoming tied to almost every other priority: AI adoption, cybersecurity, service delivery, efficiency, workforce planning, and mission resilience.

The evidence is not encouraging. In June 2019, the Government Accountability Office identified ten critical federal legacy systems most in need of modernization. In July 2025, GAO reported that, as of February 2025, only three of those ten modernization efforts had been completed. Four were expected to finish in the next few years, two were expected to take five or more years, and one still did not have a planned completion date. That is a long time for systems that were already considered critical years ago.

Congress is paying attention too. In April 2026, a bipartisan group of House lawmakers introduced the Legacy IT Reduction Act of 2026, H.R. 8408. The bill would require agency CIOs to inventory legacy systems and require agency heads to develop five-year plans to update, modernize, retire, or dispose of them. Visibility and planning will not solve modernization by themselves, but they are necessary starting points.

The bigger lesson is simple: legacy modernization fails when it is treated as a technology relocation project instead of an operational transformation project.

Why this matters now

Legacy systems are no longer just an internal IT inconvenience. They directly affect whether agencies can scale AI, defend against cyber threats, improve citizen services, and adapt to changing mission needs.

EY’s 2026 Federal Efficiency Survey found that 86% of federal decision-makers see barriers to scaling AI into agency-wide solutions. The top barrier was difficulty integrating new AI solutions with legacy IT systems, cited by 48% of respondents. Workforce skills and training gaps were also a major barrier, cited by 44%.

Those numbers matter because they connect two conversations that are often treated separately. Agencies cannot become AI-ready while leaving their core systems brittle, poorly documented, and difficult to integrate. AI does not sit above modernization. Increasingly, AI depends on modernization.

A model may be impressive in a sandbox, but production AI needs data access, system integration, identity controls, monitoring, security, workflow design, and governance. Legacy environments often make each of those harder.

The lift-and-shift trap

Lift-and-shift migration can be useful. Moving a system to cloud infrastructure may reduce data center burden, improve availability options, or create a path toward later modernization. In May 2026, a senior technology advisor at the Department of Transportation urged agencies to consider lift-and-shift strategies for modernizing legacy systems without downtime. That advice can be pragmatic in the right context.

The trap is calling that the finish line.

A cloud-hosted monolith is still a monolith. A brittle integration does not become flexible because it runs on newer infrastructure. A poorly documented business rule does not become clear because the server changed locations. A system with fragile release processes, outdated interfaces, weak observability, or hard-coded assumptions may still carry the same operational risk after migration.

Lift-and-shift may be a phase. It may buy time. It may reduce certain risks. But if the only thing that changes is where the system runs, the agency has relocated technical debt rather than modernized the system.

Modernization is really about mission knowledge

The hardest part of legacy modernization is often not the code. It is the knowledge embedded in the code.

Many legacy systems have grown around years of policy changes, operational exceptions, manual workarounds, reporting needs, and institutional habits. Some business rules were never fully documented because the people maintaining the system knew how it worked. Some data structures reflect decisions made decades ago. Some workflows exist because of constraints that no longer apply, while others exist because of legal or mission requirements that absolutely still matter.

A modernization team that does not understand those distinctions is in trouble.

This is why legacy replacement cannot begin with the assumption that the old system is simply bad and the new system will be better. The old system may be ugly, expensive, and hard to maintain, but it may also contain critical domain logic that keeps the agency functioning.

The goal is not to preserve every quirk. The goal is to understand which behaviors are accidental, which are essential, and which should be redesigned.

The skills gap is widening

Federal modernization also faces a workforce problem. The people who understand older systems, languages, interfaces, and agency-specific workflows are often approaching retirement or already stretched thin. Newer technologists may understand cloud, APIs, DevOps, modern security practices, and AI-enabled workflows, but lack the domain context embedded in the legacy environment.

That gap is where modernization projects can stall.

If legacy experts are not given time to transfer knowledge, teams lose context. If modern engineers are not exposed to the operational reality of the mission, they design elegant systems that miss important constraints. If documentation is treated as an afterthought, the new system may repeat the same dependency on tribal knowledge that made the old system fragile.

Knowledge transfer needs to be a deliverable. Not a nice-to-have. Not something squeezed into the last month of a project. A deliverable.

Political timelines and technical timelines do not always match

Federal modernization also runs into a structural timing problem. Serious modernization work often takes years. Political priorities can shift faster than that. Leadership changes, budget cycles change, oversight pressure changes, and new mandates arrive before old ones are complete.

This is one reason five-year modernization plans are useful but not sufficient. A plan can create visibility, but it still needs durable anchoring. Modernization efforts should be tied to mission outcomes, statutory requirements, cybersecurity risk, operational continuity, and measurable service improvements rather than the language of a single administration or leadership cycle.

The more a modernization effort depends on a temporary priority narrative, the easier it is for that effort to lose momentum.

What works better

Successful modernization efforts tend to follow a more disciplined pattern.

Define modernization as architectural change, not infrastructure movement: Rehosting may be useful, but real modernization improves maintainability, integration, security, observability, delivery speed, and mission adaptability.
Inventory systems honestly: Agencies need to know what exists, who owns it, what it costs, what risks it creates, what mission function it supports, and what dependencies surround it.
Document domain logic: Legacy behavior should be captured before replacement decisions are made. Teams need to know which rules matter, which are historical artifacts, and which can be simplified.
Build knowledge transfer into the plan: Pair legacy-system experts with modern engineers, analysts, and architects before institutional knowledge disappears.
Modernize incrementally where possible: Big-bang rewrites are risky. Strangler patterns, API layers, service extraction, data modernization, and phased migration can reduce disruption.
Design for continuity: Modernization plans should survive leadership changes by tying the work to mission outcomes, security risk, compliance needs, and measurable operational value.
Make integration a first-class requirement: Modern systems need to connect with AI, analytics, identity, case management, reporting, and partner ecosystems. Integration cannot be added at the end.

The common thread is that modernization needs to be treated as a program of understanding, sequencing, and execution. Not a procurement event. Not a platform swap. Not a cloud migration alone.

AI raises the stakes

AI has made legacy modernization more urgent because it exposes the weakness of brittle foundations. Agencies want AI to help with analysis, automation, fraud detection, citizen services, cybersecurity, case triage, document processing, and mission planning. But AI depends on data and workflows that are often trapped inside legacy systems.

If data is inconsistent, inaccessible, poorly documented, or hard to govern, AI will struggle. If business processes are fragmented across outdated systems, AI-enabled automation may simply amplify confusion. If identity, logging, and access controls are weak, AI introduces new governance and security risks.

This does not mean every legacy system has to be replaced before an agency can use AI. It means AI planning and modernization planning need to be connected. Otherwise, agencies may invest in AI pilots that cannot scale because the systems they depend on are not ready.

How Ridiculous Engineering thinks about modernization

At Ridiculous Engineering, we approach modernization as both a technical and domain-knowledge problem. The technology matters, but the first challenge is understanding what the existing system actually does, why it behaves that way, and which parts of that behavior need to survive the transition.

This is especially important in complex public-sector and enterprise environments where systems often encode years of policy, process, compliance, reporting, and operational exceptions. Replacing the software without understanding those rules is how modernization creates new risk.

We help organizations think through modernization in practical steps: current-state assessment, system inventory, workflow and data mapping, domain-logic discovery, integration planning, architecture evaluation, phased migration, and implementation support. The goal is to reduce risk while improving the organization’s ability to operate, integrate, secure, and evolve the system over time.

For organizations preparing for AI adoption, this work becomes even more important. AI-ready systems need accessible data, reliable integrations, governance, monitoring, and clear ownership. Legacy modernization is often the foundation that makes those capabilities possible.

Modernization has to be executable

Federal legacy modernization does not fail because agencies lack awareness. The problem is well known. It fails when plans are too vague, knowledge transfer happens too late, requirements are incomplete, timelines ignore reality, and technology choices are treated as substitutes for architectural judgment.

The Legacy IT Reduction Act points in the right direction by emphasizing inventory and planning. But legislation alone will not modernize a system. Agencies still need disciplined execution, strong discovery, durable funding, clear ownership, and teams that can translate mission needs into technical change.

If your organization is evaluating legacy modernization, preparing for AI-readiness, or trying to reduce risk in an aging application portfolio, Ridiculous Engineering can help. We work with clients to clarify the current state, capture domain knowledge, design realistic modernization paths, and build systems that are easier to operate, integrate, and improve.

Modernization is not just about replacing old technology. It is about preserving what the mission needs while removing the constraints that keep the organization from moving forward.

Sources and further reading: GAO: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems, FedScoop: Legacy IT Reduction Act of 2026, EY: Federal government agencies' efficiency efforts face significant barriers, MeriTalk: DOT advisor urges lift-and-shift path, AWS: Framework for accelerated modernization and technical debt reduction

Federal Legacy Modernization: Why Most Efforts Fail and What Works