In June of this year, the Office of the Assistant Secretary for Planning and Evaluation (ASPE) within HHS low key published one of the more illuminating pieces on the challenges of modernizing legacy systems that I have read in a while. I don't think it got all that much attention when it was released (I certainly missed it), but it is essential reading for anyone who cares about legacy modernization work in government.

The brief examines the Comprehensive Child Welfare Information System (CCWIS) program, the federal framework that is intended to support the administrative systems that states use to track child safety, placements, and services. The primary finding highlighted in the brief won't shock anyone that has worked in the government technology space, but it's disheartening nonetheless:

“After a decade and over $2.2 billion in spending, CCWIS implementation remains slow and uneven, with most resources flowing to legacy systems rather than modernization. These outcomes stem from persistent gaps in planning, governance, and readiness, not a lack of available technology or funding.”

What's really valuable about this study is that it digs into why these problems exist. And the really interesting part is that the issue is not that there isn't sufficient money to support state modernization efforts (there is!) or that the technology doesn't exist to support modern systems either (it does!).

Understanding the real challenges facing modernization of these critical state systems is essential if we're going to fix them so they work for the people that need them to work — at-risk kids.

Follow the Money

When ASPE examined where the money spent on CCWIS implementation has actually gone, they found that 85% of it (about $1.9 billion) has gone to what are called “transitional systems,” rather than newly built ones. New CCWIS development accounts for just $331 million of total spending to date.

This means the vast majority of the money that has gone out the door to support these critical state systems has gone toward maintaining outdated legacy systems, not building new ones that function more effectively.1

Transitional systems are the legacy environments states keep running while they build a modernized replacement. They're supposed to be temporary — a bridge to the future. But instead they've become the destination. On a per-year basis, the brief found that (among projects with any claims) the median transitional system costs roughly twenty times more than a new build. Federal dollars keep flowing to maintain old systems, with no firm deadline to ever turn them off.

Why are these transitional systems lingering for so long? The brief acknowledges that legacy systems with “complex or convoluted architecture and poor documentation” are hard to transition away from. There is no comprehensive set of documentation that captures what the old system does, so replacing it is risky. The rational move is to maintain the status quo. One of the key factors examined in my book on the SpecOps method, and in the other blog posts on this site, is that extreme “documentation poverty” is what keeps governments chained to outdated systems. It is one of the reasons that legacy systems linger on long past when they should be retired or replaced.

Process Compliance Isn't Readiness

The ASPE brief's core finding is that funding levels don't predict the success of legacy modernization efforts. Planning quality, governance structure, and organizational readiness do. States that start building a replacement system before they've done the foundational work required to support modernization end up with evolving requirements, rework, and timelines that stretch on for years and years.

And there is a specific point in the current CCWIS funding and oversight process where this problem manifests most acutely: the Implementation Advance Planning Document (APD).

For folks who are unfamiliar with how the federal government subsidizes the development of state-level administrative systems, states access federal money through the Advance Planning Document process.2 The APD process is a series of formal submissions and approvals across planning, implementation, and operations steps that states undertake when applying for federal funding. The Implementation APD is a critical step in this process. Review and approval of this document unlocks the federal match for design, development, and implementation (DDI). It's the trigger for states to receive money to actually build the system.

Despite its criticality, the ASPE brief found that there is “no standardized expectation for the artifacts or level of maturity required before approval of DDI funding.” So states can pass through this critical review gate with a document that essentially satisfies a compliance format (it looks right), without the business processes, data strategy, or governance structures behind it actually being sufficient. According to the brief:

“Many states begin development without these foundations in place. As a result, planning often continues into development, leading to evolving requirements, rework, and extended timelines.” [emphasis added]

States spend enormous amounts of time and money to develop their implementation APD documents, and federal agencies spend time and resources reviewing and approving them. The gate is in place, it just checks the wrong things. As it exists today, it measures the ability to comply with a bureaucratic requirement and submit an APD document that passes review. It does not measure a state's ability to successfully implement a new system. So if it's not doing that, what is it even good for?

Time for a New APD Process

The APD process was built for a world in which generating code and building software systems was enormously expensive and slow. When a build potentially takes years and costs tens of millions of dollars it seems rational to front-load an exhaustive planning and approval process. When getting it wrong means starting over, it makes sense to invest heavily up front in the hope of getting it right, because the cost of getting it wrong will get your name in the paper. The heavy APD process can be seen as a rational response to expensive, high-risk development.

That the underlying premise holding this logic together no longer holds.

When building is cheap and fast, the expensive, irreversible part of the project is no longer the code. It's knowing what to build. The scarce resource shifts from construction to a clear, verified account of how the system is supposed to behave — and that is exactly the thing the current APD process never actually pins down.

The entire premise of the SpecOps Methodology is that AI has made it practical to compile institutional knowledge into a comprehensive, human-verified specification of how a system is supposed to work, and to do it in hours and days rather than months. And, just as importantly, to generate working code from that specification once it's verified. The specification, not the code, becomes the source of truth for system behavior. Domain experts, the program people who actually understand the policy, verify it in plain language. Then, and only then, does implementation begin.

This changes the calculus on the two main problems the ASPE brief identifies.

For states that are stuck with relying on a transitional system, seemingly indefinitely, a verified specification is exactly the missing artifact they need to move away from it. A primary reason states can't move away from transitional systems is that nobody has captured what those systems do. That's the specific condition a spec-driven approach is built to solve. A comprehensive system specification can be used to capture the behavior of the existing system and verify it. With this in hand, the risk of replacement drops dramatically.

For assessing a state's readiness to implement a new system, a verified specification is a real definition of “ready.” Not an expensive document prepared by a team of outside consultants that “looks” right. Reorienting time and effort spent preparing an implementation APD document to preparing a verified system specification has real value. This reorientation would convert time spent preparing a bureaucratic APD document into developing an artifact that can support a real system implementation.

Here's My Idea

Make the Implementation APD a verified software specification.

That's it. That's the whole idea. But I think it could make a massive difference in driving the adoption of new, updated CCWIS systems to better serve at-risk kids in need.

To be clear, I'm not proposing adding a new document to the stack the APD process already requires states to submit. The ASPE brief notes that states already experience the APD process as burdensome and complex — making that problem worse won't help. The software specification I propose should absorb the planning artifacts the process already nominally requires (which includes things like functional requirements, high-level design, business process rework, etc.) and turn them into an authoritative, version-controlled blueprint that governs the build of the new system. This spec comes first. It's verified by the people who understand the program — policy experts and SMEs. And every change to the system flows back through it, so the system stays aligned with it over time.

Under this approach, the Implementation APD stops being a compliance checkpoint and becomes what its name implies: an actual plan that can be used for implementation.

But Wait, Not All States Are Stuck

It's important to consider the few instances where states were able to move away from legacy systems and put new systems in place. The ASPE brief calls out two states as successes, and it's worth examining the approach each took. Idaho and Arizona both reached fully operational status not by exhaustively documenting their old systems, but by doing something closer to the opposite: they adopted configurable products and deliberately chose not to reproduce every legacy workflow. Idaho credited that decision as a key reason it succeeded. So if the states that have seen some success achieved that by essentially throwing legacy behavior away, why spend effort capturing it in a specification?

That is precisely why a specification is critical: it enables a team to make those choices intentionally. As discussed in the brief, the root cause of failure is not a lack of configuration, but rather requirements that constantly shift during development because system expectations are never agreed upon upfront. Implementing a verified specification would drive early triage, helping distinguish core policy requirements that the system must enforce, habits disguised as requirements that can be eliminated, and features that should adapt to a configurable product. Idaho and Arizona successfully navigated these distinctions thanks to exceptionally disciplined leadership and seasoned program management (props to them). But the reality is that those things are not evenly distributed across states.

That's the real promise of a spec-first APD. It's not a mandate to rebuild the past. It's how you give every state the ability to make the deliberate keep-drop-bend decision that today depends on getting lucky with leadership.

No Silver Bullets

The brief identifies other constraints that even the best software specification can't fix: a lack of state procurement capacity, critical staff turnover, multi-year bundled contracts, legal and consent-decree complexity. A verified spec doesn't manufacture organizational readiness. In fact, it requires and channels it, which means states will need help producing a good one. That points to the brief's other big recommendation: ACF repositioning itself as an active partner in planning rather than a compliance overseer. A spec-first APD is exactly the kind of thing a federal partner could help states build.

And I don't think this requires an act of Congress or a lengthy rulemaking process to achieve. The brief argues that modernizing CCWIS guidance is largely within ACF's existing authority. Redefining what a mature Implementation APD contains is a very achievable goal.

The Window is Open

CCWIS is not a one off. The APD process governs a big chunk of federal-state technology funding, and the patterns it encourages are everywhere in government IT.

But with the maturity of new AI models and tooling, we now have options that didn't exist when these rules were written. And it's time for the rules to catch up to that fact, starting with the primary APD document that decides whether a state is ready to build a new system.

A fuller proposal outlining this idea is coming soon. But the bottom line is clear as day now. We need to stop treating the Implementation APD as a paperwork exercise, and start treating it as the blueprint for the systems that states want and that at-risk kids need.

1 This is a similar finding to one identified in a recent GAO report that looked at IT spending at large federal agencies. The GAO found that in FY 2025 about $83 billion (or 79 percent) of the $105 billion in planned total IT spending at 24 large agencies was allocated to operations and maintenance of existing systems, not modernization. ↩

2 The two main federal departments that use the Advance Planning Document (APD) process to approve and fund state information technology systems are the Department of Health and Human Services (HHS) and the Department of Agriculture (USDA). The brief discussed in this post focuses on the process used by HHS. ↩