The real project is understanding the service
A mature state system may encode years of statute, regulation, administrative interpretation, and emergency patches. Some rules will be documented; others may be understood mainly by the staff who maintain them. The important question is not simply how old the language is. It is whether the agency can explain the system's behavior and sustain the public service while changing it.
These systems can persist because replacement is risky, because integration is difficult, or because the current platform still meets important needs. That does not establish that every mainframe is reliable, economical, or secure. Unsupported components, scarce skills, and undocumented dependencies can create significant risks alongside the risk of migration.
GAO's July 2025 federal legacy-system review identified 11 systems most in need of modernization and found that only three had documented plans covering all the key elements examined. GAO emphasized milestones, the work required, and disposition of the legacy system. This is federal evidence, not a measured finding about all state COBOL programs, but the planning questions transfer usefully to state projects.
Recover the rules before selecting the destination
The business logic is an asset; COBOL is one implementation of it. Selecting a cloud target, vendor suite, or migration tool before understanding the rules risks translating an incomplete specification. A technically successful conversion can still calculate the wrong result or fail a real operational exception.
We recommend building a rule inventory that links four things:
- Authority: the policy, statute, or approved interpretation behind the behavior.
- Implementation: the code, configuration, batch process, and data on which it depends.
- Evidence: representative cases and observed results, including exceptions and reversals.
- Ownership: a program decision-maker who can resolve disagreements between current behavior and intended policy.
Pair code analysis with interviews while institutional knowledge is available. Record uncertainty explicitly. When the old system conflicts with current policy, copying its output is not a sufficient acceptance test; the program owner must decide which behavior the replacement should implement and how to handle affected records.
Sequence migration around independently testable outcomes
Incremental replacement can turn one large cutover into smaller decisions, but it introduces coexistence and integration work. It is an option to evaluate, not a universal guarantee of success. Some tightly coupled functions may need to move together; other functions can be isolated behind stable interfaces.
An illustrative sequence is:
- Instrument and document. Establish volumes, service deadlines, dependencies, failure modes, and a baseline of current behavior.
- Choose a bounded capability. Identity, correspondence, or a calculation service may be candidates, depending on the actual coupling and risk.
- Define parity and intentional differences. Compare representative outputs and document policy corrections rather than treating every difference as a defect.
- Test coexistence. Establish which system owns each record, how updates are reconciled, and how downstream consumers receive consistent information.
- Rehearse the transition. Test peak load, failure recovery, rollback triggers, and staff operating procedures before moving production traffic.
- Retire deliberately. Confirm archival, audit access, records retention, and remaining interfaces before declaring the old capability gone.
A replacement is not complete while essential nightly jobs still depend on an undocumented part of the retired platform. Budget for that final dependency work from the start.
Use AI as a discovery assistant, not an authority
Language models can help draft candidate explanations, organize code findings, and suggest test cases. Before building a schedule around promised time savings, measure the benefit on a representative slice of the agency's own system. Include the time spent correcting and validating the generated documentation.
For every generated rule explanation, require a trace to source code and tests that establish its behavior. Review data definitions, rounding, date boundaries, exceptions, and interactions with external systems. A confident explanation that misses a rare eligibility or payment case can be more damaging than an explicit unknown because it looks ready to become a requirement.
Keep sensitive code and data within approved environments, apply normal access controls, and have qualified staff review output. AI can shorten some discovery tasks; it cannot supply missing policy authority or certify that the reconstructed requirements are complete.
What leaders should fund and measure
The strongest modernization case funds understanding, controlled transition, and sustainable operation—not just a new platform. Ask the team to report the share of rules with evidence, unresolved policy questions, tested service outcomes, remaining dependencies, and recovery readiness. Avoid using converted lines of code as the main measure of public-service progress.
The mainframe can be part of the risk, and undocumented rules can remain a risk on any replacement platform. Treat both honestly. Funding the discovery and sequencing work gives the agency a basis for comparing options and costs; it does not predetermine that cloud migration, incremental replacement, or a particular vendor will be cheapest.
Sources and further reading
Spartan X’s phased modernization and data architecture services fit the difficult work between understanding a legacy system and replacing it—making dependencies visible, testing each transition, and keeping the service operating while the platform changes.
