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.
Trace one calculation all the way through
Consider a hypothetical benefits calculation that appears to disagree between the legacy system and its proposed replacement. The first task is to explain the difference. It could reflect a defect in the new code, a changed rounding rule, a different effective date, an upstream data conversion problem or an intentional correction of old behavior. Matching the old answer is not automatically the right resolution.
Build a comparison record with the original inputs, relevant dates, applicable rule, expected output and observed results from both systems. Have the program owner approve the intended behavior and the technical team trace how each implementation produced its result. Include reversals, adjustments and boundary cases rather than relying on ordinary transactions alone.
Where outputs differ intentionally, carry that decision into training, downstream reporting and the support process. Otherwise, staff may treat the new behavior as a defect and recreate the old rule through a workaround. Where the cause remains unknown, keep the uncertainty visible in the release decision.
Define the point at which rollback stops being simple
A traffic switch is only part of a cutover. Once the replacement has accepted new records or sent external instructions, returning users to the old interface may leave the underlying data inconsistent. Before migration, define which system owns writes during each stage, how changes are reconciled and what evidence confirms that reconciliation.
For a controlled transition exercise, ask operators to recover from a failed batch after some records have already been accepted. Verify which actions can be repeated safely and which require investigation. Include downstream consumers in the exercise: a balanced source database does not prove that a payment file or reporting feed received the correct version.
The alternative may be to keep a tightly coupled capability together for a larger cutover, or to defer its migration while reducing a specific operational risk on the current platform. Compare those options against measured coupling, service requirements and available skills. A phased approach is valuable when the boundaries are workable; it should not create years of unsupported dual operation by default.
The next funding decision should identify one service outcome, the evidence needed to accept it and the dependencies that must disappear before the old capability can retire. That makes the transition measurable in work the agency can perform, rather than in code translated.
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.
