Separate the case study from independent evidence
Kansas' unemployment insurance modernization offers a useful case for asking what has to change before a new platform can improve service. TCS, the implementation partner, reports a 29-month delivery and an 80 percent improvement in claim-processing times. Kansas also announced a 2025 NASCIO award for the project. These are meaningful signals, but the vendor's performance account is not an independent evaluation, and a percentage improvement needs a defined baseline before another state can use it as a planning assumption.
Kansas' own January 6, 2026 legislative briefing adds operational evidence: a November 19, 2024 go-live, over 99 percent uptime and 92 percent of UI claims using self-service. It also reports the NASCIO and AWS awards. These state-reported measures strengthen the case for a reference conversation, while still requiring definitions and measurement periods before comparison with another program.
A buyer considering the same approach should obtain the acceptance and financial records alongside the success story. The better question for buyers is: what did the team change in its data, workflow and operating model, and which of those changes can we reproduce?
Make data a design constraint
The data-first lesson begins with a practical design question: are historical claims, claimant identity, employer accounts and payment histories understood before migration begins?
Treating migration as a late technical task creates avoidable risk. Inconsistent definitions, missing fields and records that do not fit the target schema can invalidate a schedule after contracts have been signed. A data inventory and reconciliation plan make those constraints visible early, before the new platform is designed around assumptions inherited from incomplete legacy documentation.
Measure availability in resident terms
Availability deserves the same discipline: define what residents and staff can actually do, at what times, and during which failure conditions. Nightly processing windows can restrict when claimants file, employers respond and staff resolve exceptions. A replacement should specify which services remain available during batch jobs, maintenance and recovery, and how transactions reconcile when a connected system is offline.
Event-driven processing can improve timeliness, but it does not automatically require a complete data-model replacement, and a modern service can combine synchronous, event-driven and batch patterns. Buyers should compare measured user availability and recovery behavior, rather than assume a cloud platform or an architecture label guarantees 24/7 access.
Test whether the work became easier
Training time is another useful test of whether modernization changed the work. The test is practical: a new interface that preserves every manual override and exception queue may preserve the old training burden as well. Compare time to demonstrated proficiency on representative tasks, not simply time spent in a classroom. Observe how staff handle corrected claims, unusual employer records and payment exceptions.
Those cases reveal whether workflows are simpler or whether complexity has merely moved to a different screen. TCS' reported processing improvement is a reason to investigate the implementation, not proof that one requirements decision caused the outcome. Delivery teams, policy choices, testing and operations can all contribute.
Treat AI as a future capability to validate
The forward-looking value of cleaner data goes beyond the initial replacement. TCS describes possibilities for AI, advanced fraud detection and business analytics; these are opportunities, not evidence that every capability is already operational or validated. A state planning those uses should first determine whether records are complete, consistently defined, appropriately retained and lawful to use for the proposed purpose. A large migrated dataset is not automatically a clean dataset. Fraud detection requires a defensible evaluation design; an unusual claim is not proof of fraud, and an automated flag needs a review and correction process.
Better reporting can sometimes meet the operational need without a model. The durable investment is a governed data foundation and staff able to test the next capability, whether it uses AI or conventional rules.
Translate lessons instead of copying promises
For state CIOs and program directors, the Kansas example is most useful as a set of procurement and delivery questions. Audit representative data early, select architecture against service requirements, redesign unnecessary steps before encoding them, and treat staff proficiency as an outcome. Do not copy a 29-month schedule without comparing scope, legal rules, legacy dependencies and deployment risk. A successful implementation story should lead to a reference conversation, a review of acceptance evidence and a careful mapping of transferable practices.
It should not become a promise that another state will achieve the same result by purchasing the same platform. Data discipline and process redesign remain central lessons, while the evidence supporting the numerical claims must remain visible.
Evidence to request from a modernization reference
- Request the evidence pack. Ask for baseline definitions, measurement periods, scope changes, acceptance criteria and the final financial record. Separate vendor statements from state acceptance and independent assurance.
- Reconcile before cutover. Sample identities, employer balances, claims and payments across old and new systems. Document how rejected, duplicated and corrected records will be resolved.
- Test the difficult journey. Observe a claimant and a caseworker completing a normal task and an exception task. Include accessibility, low-bandwidth access and a failed dependency.
- Measure proficiency. Give trained staff representative cases and record accuracy, assistance required and completion time. Avoid treating shorter training alone as evidence of better service.
- Plan safe operations. Define rollback, incident escalation, data-quality ownership and manual continuity. Add AI only after the baseline process is measurable and its error-handling path is reliable.
Turn the reference conversation into a reconciliation exercise
Consider a hypothetical state reviewing a replacement platform. Its total claim count matches the legacy database, but a sample of records shows that adjustments are attached to the wrong benefit periods. The count is useful evidence of volume; it does not establish that the migrated service will calculate or explain the right result.
Ask the migration team to trace a representative record from source through transformation to the destination and downstream output. Include an ordinary claim, a corrected claim, an employer adjustment and a case with incomplete historical information. Use authorized test data and have program staff establish the expected interpretation before judging the output.
For each discrepancy, identify whether it arises from a source-data problem, an ambiguous definition, a transformation defect or an intentional rule change. Assign the resolution to the person who has authority over that question. A technical team can repair a mapping; it should not silently choose a program interpretation because a field must be populated.
Record both the correction and the remaining uncertainty. Reconcile values that affect the service, not only record counts, and verify downstream reports and interfaces. Define acceptance criteria before the final comparison so that a discrepancy is not dismissed merely to preserve the cutover date.
Compare the next state's conditions, not just the headline result
A reference project's reported timeline becomes more useful when buyers understand where it started. Ask what discovery had already occurred, which functions were included, which integrations moved later and how long staff operated old and new processes together. Request the measurement definition behind a processing-time improvement: the start and end events, included cases, period and treatment of exceptions.
The same discipline applies to uptime. A platform can be reachable while a resident cannot complete an essential transaction because a dependency is unavailable. Define the service journey and planned maintenance treatment before comparing availability figures. Kansas's state-reported figures are a reason to examine its operating record, not a substitute for defining the next program's requirements.
A phased transition may make sense where functions have testable boundaries. A larger coordinated cutover may be necessary where separating them creates more reconciliation risk than it removes. Stabilizing a critical legacy dependency before either approach can also be justified. Select the sequence from the actual data and service constraints, with explicit continuity and rollback limits.
The next solicitation should carry forward the practices that the buyer can verify and reproduce. That converts a promising reference into a defensible delivery plan without turning another state's reported result into an unsupported promise.
Sources and further reading
- Kansas Department of Labor legislative briefing — January 2026 operational measures and awards
- TCS Kansas implementation account — implementation partner's reported timeline, processing improvement and future capabilities
- Kansas announcement of NASCIO award — state announcement of the 2025 project award
Spartan X approaches modernization through engineering, AI consulting and program execution—the combination needed to test the data, understand the workflow and turn a vendor's reported result into a realistic requirement for the next program.
