Case Study: COBOL-to-Cloud Migration at a Government Agency

Background

The Department of Social Services for the State of Maryland (MDSS) administered a range of public benefit programs, including Temporary Cash Assistance, Supplemental Nutrition Assistance, Medical Assistance, and several smaller programs serving approximately 890,000 active beneficiaries. The core system that managed eligibility determination, benefit calculation, and payment processing was the Maryland Automated Benefits System (MABS), a COBOL application that had been in continuous operation since 1988.

MABS ran on an IBM z14 mainframe in the state's primary data center in Annapolis. The system comprised 1,340 COBOL programs, 860 copybooks, and approximately 2.8 million lines of code. It processed an average of 42,000 eligibility transactions per day and generated over $3.2 billion in annual benefit payments. During the COVID-19 pandemic, daily transaction volumes had surged to over 120,000, straining the mainframe's capacity and highlighting the system's inability to scale dynamically.

By 2023, the state faced three converging pressures. First, the mainframe hardware contract was approaching renewal, and IBM's pricing for the next-generation z16 represented a 35% increase over the current contract. Second, federal mandates from the Centers for Medicare and Medicaid Services (CMS) required states to adopt modular, interoperable system architectures under the Medicaid Information Technology Architecture (MITA) framework. Third, the state's IT workforce was aging: the average age of the COBOL development team was fifty-seven, and recruiting new mainframe developers had become nearly impossible.

Governor Michelle Torres signed an executive order in March 2023 establishing the MABS Modernization Initiative, with a directive to migrate MABS from the mainframe to a cloud-hosted environment within five years. The initiative was funded at $48 million, drawn from a combination of state appropriations and federal matching funds under the MITA framework.

The project was assigned to a newly created Modernization Office led by Deputy CIO Anthony Reeves, a career state IT professional with twenty years of experience managing large government technology projects.

The Feasibility Study

Anthony's first action was commissioning an eight-month feasibility study to evaluate the available migration options. The study team consisted of state IT staff, a consulting firm specializing in government technology modernization, and representatives from both IBM and two major cloud providers.

The feasibility study evaluated three strategic options.

Option A: Replatform. Move the existing COBOL programs, largely unchanged, from the IBM mainframe to a COBOL runtime environment hosted in the cloud. This approach preserved the existing code and minimized the risk of introducing functional defects. The primary technology choice was Micro Focus COBOL (now Rocket COBOL) running on Linux virtual machines or containers in a cloud environment. Estimated timeline: two years. Estimated cost: $18 million.

Option B: Refactor and Replatform. Move to the cloud as in Option A, but first refactor the COBOL code to eliminate mainframe-specific dependencies (CICS, JES, VSAM), modernize the data layer to use a cloud-native database, and restructure programs into modular services. Estimated timeline: three and a half years. Estimated cost: $32 million.

Option C: Full Rewrite. Rewrite the entire system in a modern language (Java or Python) on a cloud-native architecture. Estimated timeline: five years. Estimated cost: $48 million, consuming the entire budget with no contingency.

Anthony convened a decision board that included the Secretary of Social Services, the State CIO, and federal CMS representatives. He presented the feasibility study's findings along with a risk assessment for each option.

Option C was eliminated quickly. The risk data was unambiguous: government IT rewrites of systems exceeding one million lines of code had a failure rate exceeding 60% nationally. The State of California's failed unemployment system rewrite, which had consumed $110 million before being abandoned, was cited as a cautionary example. CMS representatives confirmed that federal matching funds would not be available for a full rewrite without evidence of successful incremental delivery.

The choice between Options A and B was more nuanced. Option A was faster and cheaper but would leave the state running 1990s-era COBOL code on cloud infrastructure, gaining scalability but not agility. Option B was more expensive and complex but would produce a system that was genuinely modernized and positioned for future evolution.

The board chose a hybrid approach: begin with Option A to achieve the immediate goal of leaving the mainframe, then pursue the refactoring activities of Option B as a second phase once the system was stable on cloud infrastructure. This approach limited risk while preserving the long-term modernization vision.

Phase 1: Replatforming to Cloud

The replatforming phase targeted moving MABS from z/OS to COBOL running on Linux in a major cloud provider's infrastructure. The technical migration involved four major workstreams.

Workstream 1: COBOL Runtime Environment

The team selected Micro Focus Enterprise Server as the COBOL runtime environment for the cloud deployment. Enterprise Server provided a COBOL compiler and runtime that could execute programs originally written for z/OS without modification in most cases. It also provided emulation of CICS (through its Enterprise Server for CICS functionality), JCL (through its JCL engine), and VSAM (through its file handling capabilities).

The initial compatibility testing revealed that 94% of MABS programs compiled and executed correctly on Enterprise Server without modification. The remaining 6% required changes, falling into several categories.

Programs using IBM-specific compiler extensions required the most attention. Several programs used the IBM COBOL compiler's support for nested programs in ways that the Micro Focus compiler handled differently. Others used IBM-specific intrinsic functions or made assumptions about character encoding that differed between EBCDIC (mainframe) and ASCII (Linux).

      * EXAMPLE: EBCDIC/ASCII difference requiring modification
      * On the mainframe, LOW-VALUES sorts before spaces
      * On ASCII-based systems, this ordering is preserved
      * but numeric comparisons of PIC X fields differ

      * ORIGINAL - Relied on EBCDIC collating sequence
       IF WS-SORT-KEY-1 < WS-SORT-KEY-2
           PERFORM 2100-SWAP-RECORDS
       END-IF

      * MODIFIED - Explicit collating sequence specification
      * when sort order matters for business logic
       IF FUNCTION ORD(WS-SORT-KEY-1(1:1)) <
          FUNCTION ORD(WS-SORT-KEY-2(1:1))
           PERFORM 2100-SWAP-RECORDS
       END-IF

The team also discovered that several programs contained hard-coded assumptions about record lengths and file block sizes that were valid on z/OS but incorrect in the Linux environment. These required careful analysis and correction.

Workstream 2: Data Migration

MABS used a combination of DB2 and VSAM for data storage. The DB2 data was migrated to PostgreSQL, an open-source relational database that provided SQL compatibility at a fraction of the licensing cost. The VSAM files were converted to Micro Focus file formats that preserved the KSDS, ESDS, and RRDS access patterns.

The DB2-to-PostgreSQL migration required modifications to embedded SQL statements in 187 programs. Most changes were minor: DB2-specific functions were replaced with PostgreSQL equivalents, and a few SQL syntax differences were addressed. However, several programs used DB2-specific features that required more substantial rework:

      * ORIGINAL - DB2-specific syntax
           EXEC SQL
               SELECT ELIG_STATUS,
                      BENEFIT_AMOUNT,
                      CHAR(EFFECTIVE_DATE, ISO)
               INTO  :WS-ELIG-STATUS,
                     :WS-BENEFIT-AMOUNT,
                     :WS-EFFECTIVE-DATE
               FROM  ELIGIBILITY
               WHERE CASE_NUMBER = :WS-CASE-NUMBER
               AND   PROGRAM_CODE = :WS-PROGRAM-CODE
               FETCH FIRST 1 ROW ONLY
               WITH UR
           END-EXEC

      * MODIFIED - PostgreSQL-compatible syntax
           EXEC SQL
               SELECT ELIG_STATUS,
                      BENEFIT_AMOUNT,
                      TO_CHAR(EFFECTIVE_DATE, 'YYYY-MM-DD')
               INTO  :WS-ELIG-STATUS,
                     :WS-BENEFIT-AMOUNT,
                     :WS-EFFECTIVE-DATE
               FROM  ELIGIBILITY
               WHERE CASE_NUMBER = :WS-CASE-NUMBER
               AND   PROGRAM_CODE = :WS-PROGRAM-CODE
               ORDER BY EFFECTIVE_DATE DESC
               LIMIT 1
           END-EXEC

The data migration itself was executed over a three-day weekend. The total data volume was approximately 4.2 terabytes. Extract programs running on the mainframe wrote data to flat files, which were transferred to cloud storage and then loaded into PostgreSQL using bulk load utilities. VSAM files were converted using Micro Focus data migration tools.

A comprehensive reconciliation process compared record counts, hash totals, and sampled record-by-record comparisons between the mainframe and cloud databases. The reconciliation identified twelve discrepancies, all traced to data encoding differences in free-text comment fields that contained special characters. These were resolved with character encoding corrections.

Workstream 3: Batch Processing

MABS relied heavily on batch processing. Over 180 batch jobs ran nightly, processing eligibility redeterminations, benefit calculations, payment file generation, and federal reporting. On the mainframe, these jobs were orchestrated by JES2 and CA-7 (a workload scheduling product).

In the cloud environment, the team replaced CA-7 with an open-source workload scheduler (Apache Airflow) that triggered batch jobs in the correct sequence based on dependencies. The JCL procedures were translated to shell scripts that invoked the COBOL programs through the Micro Focus runtime:

#!/bin/bash
# Converted from JCL: ELIGBAT1 - Nightly Eligibility Processing
# Original JCL Step: STEP010 - Process eligibility redeterminations

export COBDIR=/opt/microfocus/es
export COBPATH=/opt/mabs/programs
export DD_ELIGFILE=/data/mabs/vsam/eligibility.dat
export DD_CASEFILE=/data/mabs/vsam/casemaster.dat
export DD_REPORTFL=/data/mabs/reports/elig_report_$(date +%Y%m%d).dat

cobrun ELIGRD01
RC=$?

if [ $RC -gt 4 ]; then
    echo "ELIGRD01 failed with return code $RC"
    exit $RC
fi

Workstream 4: Online Transaction Processing

The CICS online components of MABS, which served approximately 3,200 caseworkers statewide, were migrated to Micro Focus Enterprise Server's CICS emulation. The BMS maps were converted to HTML templates through Enterprise Server's web-enablement feature, allowing caseworkers to access the system through web browsers rather than 3270 terminal emulators.

This was one of the most visible improvements of the migration. Caseworkers who had been using green-screen terminals for decades suddenly had a web-based interface that, while functionally identical, was more accessible and could be used from any device with a browser. The underlying COBOL programs were unchanged; only the presentation layer was different.

Containerization Strategy

A key architectural decision was how to deploy the COBOL workloads in the cloud. The team evaluated three deployment models: virtual machines, containers, and serverless functions.

Virtual machines were the simplest option but the least efficient. Each VM would run a full Linux operating system, consuming resources even when idle. Given MABS's batch-heavy workload pattern, where processing demands peaked overnight and dropped during daytime hours, the cost of idle VMs would be substantial.

Serverless functions were the most efficient but incompatible with the Micro Focus runtime environment, which required persistent processes and file system access.

Containers, specifically Docker containers orchestrated by Kubernetes, offered the best balance. The team built container images that included the Micro Focus runtime, the COBOL programs, and the necessary configuration. Kubernetes managed scaling: during the nightly batch window, additional container instances were spun up automatically to handle the processing load, and during quiet periods, the cluster scaled down to minimize cost.

# Kubernetes deployment for MABS batch processing
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mabs-batch-processor
  namespace: mabs-production
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mabs-batch
  template:
    metadata:
      labels:
        app: mabs-batch
    spec:
      containers:
      - name: mabs-cobol-runtime
        image: mabs-registry/cobol-runtime:2.1.0
        resources:
          requests:
            memory: "4Gi"
            cpu: "2"
          limits:
            memory: "8Gi"
            cpu: "4"
        volumeMounts:
        - name: vsam-data
          mountPath: /data/mabs/vsam
        - name: report-output
          mountPath: /data/mabs/reports
      volumes:
      - name: vsam-data
        persistentVolumeClaim:
          claimName: mabs-vsam-pvc
      - name: report-output
        persistentVolumeClaim:
          claimName: mabs-reports-pvc

The containerized deployment enabled a capability that was impossible on the mainframe: horizontal scaling of batch processing. On the mainframe, the nightly eligibility batch ran as a single sequential job, processing 890,000 cases in approximately four hours. In the cloud environment, the team partitioned the workload across multiple container instances, each processing a subset of cases in parallel. This reduced the batch window from four hours to forty-five minutes.

Managing the Transition

The most challenging aspect of the migration was maintaining uninterrupted service during the transition. MABS processed benefit payments for nearly 900,000 people; any disruption could delay payments to vulnerable populations and trigger federal compliance violations.

The team implemented a parallel-run strategy that operated both environments simultaneously for three months. During this period, every transaction was processed on both the mainframe and the cloud system, and an automated comparison tool verified that both systems produced identical results.

The parallel run uncovered seventeen discrepancies, all of which were resolved before cutover. The most significant was a difference in how the mainframe and Linux platforms handled packed decimal arithmetic at boundary values. A benefit calculation that involved dividing by a number very close to zero produced different results due to differences in intermediate precision:

      * Calculation that produced different results due to
      * platform-specific decimal precision handling.
      * Mainframe rounded intermediate result differently.
       COMPUTE WS-DAILY-BENEFIT ROUNDED =
           WS-MONTHLY-BENEFIT / WS-DAYS-IN-PERIOD
           ON SIZE ERROR
               MOVE ZERO TO WS-DAILY-BENEFIT
               PERFORM 8500-LOG-PRECISION-ERROR
       END-COMPUTE

      * Fix: Explicit intermediate precision control
       COMPUTE WS-BENEFIT-NUMERATOR =
           WS-MONTHLY-BENEFIT * 100
       END-COMPUTE
       COMPUTE WS-DAILY-BENEFIT ROUNDED =
           WS-BENEFIT-NUMERATOR / WS-DAYS-IN-PERIOD / 100
           ON SIZE ERROR
               MOVE ZERO TO WS-DAILY-BENEFIT
               PERFORM 8500-LOG-PRECISION-ERROR
       END-COMPUTE

The final cutover occurred over a long holiday weekend. The mainframe was taken offline Friday evening, a final data synchronization was performed, and the cloud system was activated as the system of record. Monday morning, 3,200 caseworkers logged into the web-based interface and resumed their work. The mainframe was kept available in standby mode for thirty days as a rollback option but was never needed.

Results and Ongoing Modernization

The Phase 1 replatforming was completed in twenty-six months, four months beyond the original twenty-two-month estimate, at a cost of $21.3 million, approximately 18% over the $18 million budget. The overruns were attributed primarily to the data migration complexity and the extended parallel-run period.

The benefits were immediate and measurable. Annual infrastructure costs dropped from $6.8 million (mainframe hardware, software, and facilities) to $2.9 million (cloud infrastructure and licensing), a 57% reduction. The dynamic scaling capability eliminated the capacity constraints that had caused service degradation during the pandemic surge. The nightly batch window decreased from four hours to forty-five minutes, opening the possibility of more frequent processing cycles in the future.

Phase 2, the refactoring effort, began six months after the successful cutover. The team is progressively restructuring the COBOL programs to eliminate the emulated CICS dependency, replace the converted VSAM files with PostgreSQL tables, and expose core business functions as REST APIs. This work is expected to take an additional three years and will position MABS for eventual component-by-component replacement with modern technology as business needs dictate.

Lessons Learned

Anthony Reeves documented the following lessons from the MABS migration.

A replatform-first strategy reduces risk dramatically. By separating the infrastructure migration from the code modernization, the team limited the number of variables that could go wrong at any given time. The COBOL programs on the cloud platform behaved identically to their mainframe counterparts, which meant that any problems during the transition could be attributed to infrastructure rather than logic changes.

EBCDIC-to-ASCII conversion is not trivial. While character data converted cleanly in most cases, packed decimal fields, sort sequences, and special characters all required careful attention. The team underestimated this effort initially and had to add two months to the schedule to address encoding-related discrepancies.

Parallel running is essential for government systems. The three-month parallel run was expensive (it required maintaining both environments simultaneously), but it was non-negotiable given the system's impact on vulnerable populations. The seventeen discrepancies found during parallel running would have been production defects without this safety net.

Cloud cost management requires active attention. In the first month after cutover, cloud costs were 40% higher than projected because the auto-scaling configuration was too aggressive, spinning up additional capacity at utilization levels that did not actually require it. Tuning the scaling parameters to match actual workload patterns brought costs in line with projections.

Federal partnership was essential. CMS's support for the MITA-aligned approach, including their willingness to provide enhanced federal matching funds (90% federal / 10% state), made the project financially feasible. Early and frequent engagement with CMS ensured that the technical approach met federal requirements and that funding remained secure throughout the project.

Conclusion

The Maryland MABS migration demonstrates that government COBOL systems, even those serving nearly a million beneficiaries, can be successfully moved from mainframe to cloud environments. The key to Maryland's success was a pragmatic strategy that prioritized risk management over architectural purity. By replatforming first and refactoring second, the state achieved immediate cost savings and scalability improvements while preserving the option to modernize the application architecture over time. For other government agencies facing similar mainframe exit pressures, the MABS experience offers a proven template: move the infrastructure first, modernize the application second, and never lose sight of the fact that the system's primary purpose is serving the public.