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.
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.
