THE WELFARE STACK
DEEP DIVE | ISSUE NO. 001 | {{current_date_full}}
Hey {{first_name|guys}},
THE THESIS
Everyone is thinking about CCWIS wrong…
Child welfare technology modernization goes wrong when states treat a federal funding and governance framework as a single technology product. That framing encourages comprehensive procurements, tightly coupled implementations, and success measures centered on delivery and compliance. States should instead use CCWIS as a funding mechanism as they govern a modular technology ecosystem to retain control of their data, architecture, integrations, and long-term roadmap.
In conversations about child welfare technology, people talk about CCWIS as if it is the system itself. A state is “buying a new CCWIS.” A vendor is “building the CCWIS.” Workers are frustrated with “the CCWIS.” Leaders ask when “the CCWIS” will finally go live. But this way of thinking about CCWIS hides a deeper problem: the prevailing conceptual model of CCWIS itself is contributing to the stalled and unsuccessful projects we are seeing across the country. CCWIS is not really the thing being built. CCWIS is a federal funding and governance mechanism that shapes how states finance, structure, oversee, and modernize child welfare information systems.
That distinction matters more now than ever because many states are still trying to escape the limitations of legacy SACWIS-era systems while also responding to new expectations around modularity, interoperability, data quality, reporting, and user experience. We are at a point where technology modernization cannot just mean replacing one large system with another. If states keep treating CCWIS as the product, they will keep recreating the same problems - just in a cloud environment instead of on a mainframe.
Why it matters: If CCWIS is misunderstood, states will continue to organize modernization around large procurements, fixed scopes, and long implementation timelines rather than around adaptability and continuous improvement. Projects will continue to struggle with scope creep, delayed launches, expensive change orders, and systems that are difficult to adjust once real users begin working in them. States will also continue locking themselves into large single vendor controlled environments where the vendor effectively owns the data, the integrations, the workflows, and the roadmap - because to switch would mean another large monolithic system replacement. When that happens, agencies do not just buy software; they give up leverage. They become dependent on one vendor for every major change, every reporting need, every data extract, and every future modernization decision. The cost is not only financial - it is operational. Frontline workers remain stuck with tools that are hard to use, leaders remain stuck with data they cannot easily trust or access, and the agency remains trapped in a technology environment it cannot meaningfully control.
The conventional wisdom
The conventional view is that CCWIS is the modern comprehensive child welfare technology itself. Under this view, a state has an old legacy system and needs to replace it with a new CCWIS. The basic project is to procure a vendor, gather requirements, configure the system, migrate data, train users, launch the new platform, and eventually turn off the old one.
It is understandable why people think this way. Child welfare agencies need to document cases, support federal reporting, manage workflows, track placements, process payments, and maintain data across the life of a case. States also need to meet federal requirements and justify federal financial participation. In that sense, it is very reasonable that leaders and staff describe the system they use every day as “the CCWIS.”
But that mindset is a strategic mistake and can cause detrimental outcomes for your project.
The argument: CCWIS is a mechanism, not the destination
CCWIS is not the system. CCWIS is the federal funding and governance structure that helps states build and improve child welfare technology. Once leaders understand that difference, the goal shifts from buying one large replacement system to building a modern, modular, governed technology stack that can evolve over time - an ecosystem of technology that can be as flexible as we need it to be.
When a state treats CCWIS as “the system,” success naturally becomes tied to implementation. Did the procurement move forward? Did the vendor deliver the modules? Did the data migration work? Did the system pass review? Did it go live? Those are important milestones, but they are not the same as asking whether the agency is actually better equipped to serve children and families.
A state can successfully launch a new system and still fail to modernize. Workers may still face too many screens, too many fields, duplicate entry, and no useful information at the moment they need it. Supervisors may still lack timely visibility into practice. Leaders may still lack the information necessary to connect their efforts to outcomes. That happens when modernization is defined as system replacement rather than operational improvement.
If CCWIS is understood as a mechanism that supports modernization rather than the destination of modernization itself, then the better question is not, “What CCWIS should we buy?” The better question is, “What child welfare technology environment do we need, and how can CCWIS funding help us build it the right way?”
That question opens up the strategy. It allows leaders to think in terms of capabilities, data flows, workflows, integration, product ownership, and long-term adaptability. It also allows them to separate what must be part of the core system of record from what could be handled through modular tools, enterprise services, or specialized applications.
The system of record is not the entire ecosystem
A modern child welfare environment is not a single application - it is a connected ecosystem of services that work together. It includes intake, investigation, ongoing services, foster care, adoption, licensing, provider management, eligibility, payments, document management, court interfaces, analytics, federal reporting, communications, identity management, secure data exchange with other systems, and unique functionality for different jurisdictions.
Each of these components plays a different role within the ecosystem. They serve different users, carry different risks, and operate on different rhythms. A hotline worker making an intake decision is working in a moment of urgency and uncertainty. A fiscal worker processing payments is focused on accuracy, compliance, and timing. A foster parent recruiter is building relationships and managing placement capacity. When all of these needs are forced into a single application, the ecosystem becomes strained. The system of record starts to behave like it is responsible for everything, rather than serving as one critical layer within a broader environment. The result is often a platform that is overextended in some areas, underpowered in others, and difficult to evolve anywhere. Every change becomes high-risk because it touches the entire structure.
This is where the ecosystem concept matters. A well-governed child welfare technology ecosystem allows states to intentionally distribute capabilities across multiple components. Some functions belong in the core system. Others are better served through modular applications, shared services, or specialized tools. Others still should be external systems that integrate cleanly through well-defined interfaces.
In this model, modernization is not about expanding a single system until it absorbs everything. It is about designing and maintaining a healthy ecosystem where each component has a clear role, and where data, workflows, and user experiences move smoothly across boundaries.
The answer is not fragmentation. An ungoverned ecosystem can become chaotic, with disconnected tools and inconsistent data. But the answer to fragmentation is not rebuilding a monolith. The answer is intentional ecosystem design: clear architecture, shared data standards, strong security controls, consistent integration patterns, defined product ownership, and disciplined governance across the entire environment.
The evidence: The evidence is the repeated pattern of child welfare technology projects. States replace legacy systems, but many of the same problems return under new names: long procurement timelines, large requirements documents, complex configurations, user frustration, expensive change orders, difficult reporting, and limited adaptability after go-live.
An analysis published by ASPE found that, nearly a decade after the CCWIS regulation was introduced, implementation remained slow and uneven: only 10 percent of new CCWIS projects were considered fully operational, projects had been underway for a median of roughly six years, and 32 states and territories had gone more than five years without reaching operational status. At the same time, federal and state claims exceeded $2.2 billion, with 85 percent of that spending supporting transitional legacy systems rather than new CCWIS builds. The report concluded that these outcomes reflect persistent gaps in planning, governance, organizational readiness, procurement capacity, and alignment between program and technology leadership.

This pattern suggests the problem is not only outdated software. It is the conceptual model behind the modernization effort. If the project is framed as replacing “the CCWIS,” the work tends to organize around procurement, compliance, and implementation. If the project is framed as building a modern child welfare technology stack with CCWIS as a funding and governance mechanism, the work can organize around capabilities, users, data, and long-term improvement.
The difference is not academic. It changes what gets funded, what gets prioritized, what gets integrated, what gets measured, and what leaders consider success.
YES, BUT
The strongest objection is that this distinction may sound too technical. People often use “CCWIS” to mean the system itself, and in everyday conversation that shorthand is fine.
But it becomes a problem when vernacular drives strategy. If leaders think the goal is simply to “buy a CCWIS,” success becomes about procurement and launch. If they instead see CCWIS as a funding and governance tool, they focus on whether the broader technology environment actually improves workflows, data, and integration over time.
The bottom line: A leader who understands this concept deeply should stop asking only, “How do we replace our CCWIS?” The better move is to map the agency’s full child welfare technology environment and separate it into three categories: the core system of record, the modular tools or services that should surround it, and the data and governance layer that should connect everything together. That exercise changes the modernization conversation immediately. It forces leaders to ask what actually belongs in the core system, what should be integrated, where workers experience the most burden, where data breaks down, which workflows are being preserved without question, and which investments will make the agency more adaptable over time.
CCWIS is not the system. It is a way to fund and govern the modernization of your environment.
The real goal is not to buy a better CCWIS. The real goal is to build a better child welfare technology ecosystem.
Where does this argument break down?
Hit reply — the sharpest counterarguments shape the next issue.
