Legacy Transformation · Public Sector

Federal COBOL Modernization

Federal civilian agency · 40-year-old benefits system

67% processing speed improvement
31 undocumented integrations found

Note: This engagement was completed during a period when Shelorve supported federal agency clients. Shelorve's current practice focuses on Financial Services, Healthcare, Manufacturing, Logistics & Supply Chain, and Retail.

The challenge

The agency's benefits processing system had been built on IBM COBOL in the early 1980s and had not been substantially modified since. It processed benefits claims for approximately 4.2 million recipients annually across a network of state agencies and federal reporting systems. Processing time for complex claims averaged 22 minutes. The system ran on mainframe infrastructure that was approaching end-of-support, creating both operational risk and significant licence cost exposure.

Previous assessments had identified the system as a priority for modernisation but had repeatedly concluded that the migration risk was too high to proceed. The concern in each case was the same: nobody could fully account for what the system connected to, and the consequences of a benefits processing outage — citizen services disruption, Congressional scrutiny, potential regulatory findings — made the risk of discovery-during-migration unacceptable.

The approach

Shelorve deployed CodeSight™ across the entire benefits processing environment — the mainframe COBOL codebase, the JCL batch job library, the network infrastructure, and the interfaces with state agency systems and federal reporting platforms. The discovery ran for eight weeks, covering full monthly and quarterly processing cycles to ensure batch jobs that ran infrequently were captured.

CodeSight identified 31 undocumented integrations. Of these, 14 were batch file transfers between the COBOL system and state agency systems that had been established informally over thirty years and were tracked only in the institutional memory of staff who had since retired. 12 were direct database connections from federal reporting systems into mainframe data stores. 5 were configuration-level references to external services that had been added during emergency fixes and never formally documented.

Each of the 31 integrations was documented, assigned an owner, assessed for FedRAMP compliance requirements, and addressed in the migration sequence. The COBOL business logic was migrated to AWS Lambda functions on GovCloud, with DynamoDB replacing the mainframe data stores. FedRAMP High authorisation was maintained throughout by restricting all data processing to FedRAMP-authorised GovCloud regions and maintaining continuous monitoring as required by the ATO.

The outcome

Benefits claims processing time fell from 22 minutes to 7.3 minutes on average — a 67% improvement — enabling the agency to process the same volume with fewer resources. Mainframe licence costs were eliminated. The 31 undocumented integrations are now documented, monitored, and covered by formal data sharing agreements. FedRAMP High authorisation was maintained throughout the 18-month programme with no findings. The migration has subsequently been cited internally as a template for other legacy systems across the agency's technology estate.

"Every previous assessment of this system concluded that migration risk was too high. CodeSight changed that conclusion — because for the first time, we could see exactly what the risk was. You cannot manage risk you cannot see."

— Programme Director, Federal Civilian Agency
Technology

CodeSight™ · Lambda · DynamoDB · CDK · API Gateway · AWS GovCloud

How did CodeSight handle a 40-year-old COBOL codebase?

CodeSight's static analysis handles COBOL natively. The platform parses COBOL source, JCL procedures, and COPYBOOK definitions to identify database calls, file references, and external system connections in the code. This was combined with network traffic monitoring and mainframe batch log analysis to capture the runtime behaviour across a full monthly and quarterly cycle. The 40-year age of the codebase made the multi-lens approach especially important — a large proportion of the undocumented integrations were visible only in runtime and network data, not in the COBOL source.

How was FedRAMP compliance maintained during active migration?

Shelorve maintained the agency's existing ATO throughout the migration by ensuring that at every point in the programme, all data processing occurred in FedRAMP-authorised environments — either the legacy mainframe operating under the existing ATO, or the new GovCloud environment operating under the same ATO. No data was processed in non-FedRAMP environments at any point. Continuous monitoring was maintained throughout, and the continuous monitoring evidence package was updated at each phase completion.

How was the migration sequenced around the 31 undocumented integrations?

Each undocumented integration was risk-scored using CodeSight's three-dimension ranking: blast radius (how many systems depend on this integration), criticality (what citizen service fails if this breaks), and complexity (how difficult to replicate in Lambda). High-criticality integrations — those that would cause immediate citizen-facing service disruption — were migrated last, after surrounding dependencies had been stabilised and validated. This sequencing is the reason the programme completed without a single unplanned citizen service outage.

Work With Shelorve

This could be
your story.

Tell us what you are trying to fix. We will tell you whether Shelorve is the right partner — and if we are not, we will tell you that too.