Overview — the legacy problem is not going away
The Government Accountability Office has tracked federal legacy IT on its High-Risk List since 1997. The numbers have not materially improved. The IRS still runs Individual Master File logic written in the 1960s. The Social Security Administration's core systems process tens of millions of daily transactions through COBOL. The Department of Defense has hundreds of PowerBuilder and VB6 applications running operational workflows. The cost of federal legacy is measured not just in dollars but in mission: outages that cascade, analysts who wait hours for reports, and policy changes that take years to implement because no one knows what line 4,812 of the batch job actually does anymore.
Precision Delivery Federal LLC treats legacy modernization as a craft discipline, not a slide deck. We are a SAM.gov registered small business (UEI Y2JVCZXT9HP5, CAGE 1AYQ0, NAICS 541512). Our modernization practice combines hands-on experience with mainframe and legacy Windows stacks, modern cloud-native engineering, and the one thing the government has been short of: the discipline to ship increments instead of architectures.
Our technical stack
| Layer | Primary | Alternates | When we use it |
|---|---|---|---|
| Mainframe languages | IBM Enterprise COBOL 6.4 | Micro Focus COBOL, GnuCOBOL | Refactor and facade work on z/OS. |
| Mainframe data | DB2 for z/OS, IMS, VSAM | IDMS, Adabas | Replicate to cloud via CDC; keep mainframe as SoR. |
| Mid-range | IBM i RPG IV, CL, SQL | Unisys OS 2200 COBOL | AS/400 modernization. |
| Legacy Windows | PowerBuilder 2022, VB6, Delphi | Classic ASP, WinForms | Understand, characterize, facade. |
| Target stack | Python + TypeScript + PostgreSQL | Java + Spring, .NET 8, Go | Per program preference. |
| Integration | IBM MQ bridges, REST adapters | Kafka, gRPC, CICS Transaction Gateway | Stitch old and new together. |
| CDC / replication | Qlik Replicate (Attunity) | Debezium, IBM InfoSphere CDC, Oracle GoldenGate | Parallel-run and gradual cutover. |
| LLM-assisted refactor | Claude 3.5/4 via Bedrock | GPT-4 via Azure OpenAI | Test-gated translation, review-mandatory. |
| Characterization testing | pytest-golden, Approvaltests | Custom harnesses | Capture current behavior before change. |
| Static analysis | SonarQube, Semgrep | CAST, Micro Focus Enterprise Analyzer | Code inventory and dependency graph. |
Federal use cases
- IRS modernization — Individual Master File and ancillary batch systems. IRS page.
- SSA modernization — benefits adjudication, earnings record, MBR systems. SSA page.
- VA benefits modernization — BDN, BIRLS, VETSNET decomposition. VA page.
- USDA FSA system modernization — farm program payment systems still on AS/400. USDA page.
- DoD personnel and pay — DJMS, DCPS, MilPDS modernization touch-points. DoD page.
- Treasury payment systems — PAM, SPS, and Fiscal Service modernization.
- USCIS case management — ELIS, CLAIMS 3 / 4 modernization. DHS page.
- HHS grants management — legacy grants systems feeding modern interfaces.
- FAA ATC system modernization — ERAM, STARS, TFMS touch-points.
- State Department consular systems — CCD, NIV, IV modernization periphery.
Reference architectures
1. Strangler-fig with mainframe as system of record
A public-facing React + FastAPI application fronts a legacy mainframe. REST adapters translate HTTP requests into CICS Transaction Gateway calls; responses flow back through the same layer. New functionality is built directly in the cloud-native tier, backed by a replicated PostgreSQL copy of mainframe data (CDC via Qlik). Over time, write paths migrate from CICS to PostgreSQL one use case at a time, with reconciliation jobs verifying convergence. The mainframe remains the SoR until the last consumer is migrated — which may be years, and that's OK.
2. LLM-assisted COBOL-to-Java translation pipeline
A characterization test suite is generated from existing JCL batch logs — every production run becomes a test case. Claude 3.5 via Bedrock translates COBOL paragraphs into Java with explicit prompts to preserve decimal precision and copybook structure. The translated Java runs against the test suite; failures become prioritized review tasks. Coverage tracked as % of COBOL LOC with passing translated Java. Humans review every change before merge. We budget 30-60 % speedup over greenfield Java authoring — not 10x, not "AI does the whole thing."
3. PowerBuilder UI replacement with preserved backend
An internal DoD PowerBuilder application fronted by Oracle. The Oracle schema is left intact. A new React + Tailwind UI talks to a thin FastAPI backend that embeds the existing Oracle stored procedures. Users switch screen-by-screen; both UIs coexist during the transition. PowerBuilder retires when the last workflow migrates.
Delivery methodology
- Discovery & inventory (4-8 weeks) — catalog programs, copybooks, data stores, interfaces, batch schedules, user workflows. Static analysis + operator interviews.
- Characterization (overlapping) — capture current behavior with golden tests. You cannot safely refactor what you cannot verify.
- Risk-weighted roadmap — rank modules by change frequency × business criticality × modernization feasibility. Start with highest-value, lowest-risk.
- Incremental strangler — 2-week increments. Each increment ships something real: a new API, a retired screen, a migrated table.
- Parallel-run & cutover — production traffic mirrored, reconciled, and slowly shifted. Rollback plan on every cutover.
- Retirement — decommission legacy only after the replacement has been fully authoritative for a defined quiet period (typically 90-180 days).
Engagement models
- SBIR Phase I fixed-price — modernization feasibility study + proof-of-concept strangler slice.
- Fixed-price modernization increment — single well-bounded module, capped risk.
- T&M modernization program — multi-year scope.
- TMF-funded engagements — shape the TMF business case and deliver against it.
- Sub to prime — specialist strangler engineering under a prime-led modernization.
Maturity model
- Level 1 — Lift & shift: legacy runs in cloud VMs; no code changes. Fastest, least valuable.
- Level 2 — Re-platform: COBOL moved to Micro Focus on Linux, or RPG to open platforms. Same code, new runtime.
- Level 3 — Re-front: modern UI and API layer in front of legacy core.
- Level 4 — Incremental rewrite: strangler-fig migration with test-gated increments. Legacy shrinks.
- Level 5 — Retired: legacy decommissioned, modern stack authoritative, lessons captured.
Deliverables catalog
- Program inventory (CSV + dependency graph).
- Copybook and schema catalog.
- Characterization test suite.
- Risk-weighted modernization roadmap.
- Facade APIs (OpenAPI specs + code).
- CDC / replication pipelines.
- Replacement UIs (React + Tailwind + a11y).
- Reconciliation dashboards.
- Cutover plans + rollback playbooks.
- Decommissioning checklist.
- TMF business case inputs (when applicable).
Technology comparison — modernization patterns
| Pattern | Strengths | Weaknesses | Federal fit |
|---|---|---|---|
| Encapsulate (facade) | Fastest; preserves SoR; low risk. | Doesn't reduce legacy tech debt. | High — first move for most programs. |
| Rehost (lift & shift) | Fast, contractor-friendly. | Moves problem to the cloud. | Medium. |
| Replatform | Modernizes runtime without rewriting. | Still tied to legacy language. | High for COBOL on Linux. |
| Refactor | Incremental improvement. | Slow ROI. | Medium. |
| Rearchitect (strangler) | Real modernization; low risk per step. | Requires discipline. | Very high. |
| Rebuild | Clean slate. | High cost, high risk. | Low — rarely appropriate. |
| Replace (COTS) | Offloads sustainment. | Fit gaps, vendor lock. | Case-by-case. |
Federal compliance mapping
- CM-2, CM-3, CM-8 — configuration management and inventory for the transition period when both old and new exist.
- SA-8 — security engineering applied to facade and replacement components.
- CP-10 — rollback plans on every cutover to preserve information system recovery.
- AU-2, AU-12 — audit coverage maintained across both systems during parallel-run.
- SI-10 — input validation explicitly re-evaluated at each new API boundary.
Sample technical approach — benefits adjudication strangler
A federal benefits agency runs a 40-year-old COBOL + DB2 adjudication engine on z/OS. A growing % of eligibility rules come from recent legislation and the mainframe implementation takes 9-18 months to ship each change. The agency wants faster policy agility without breaking pay-out integrity.
Discovery: we catalog the ~2,400 programs, ~180 copybooks, ~60 DB2 tables, and 40 years of batch JCL. Static analysis + interviews. Output: dependency graph and risk-weighted roadmap.
Characterization: 12 weeks to build a characterization test suite from 90 days of production JCL logs. Every batch run produces a golden set we can regression test against.
First slice: a new rules engine in Python behind a FastAPI façade. For the two most-changed eligibility rules (representing ~40 % of change frequency), new rule evaluations execute in Python; mainframe still processes payments. Reconciliation job compares Python decisions to COBOL decisions nightly; divergence = bug.
Parallel-run: 90-day shadow mode. Adjudicators see both outcomes, flag divergences, we fix. Day 91: Python becomes authoritative for those two rules. Mainframe batch stops evaluating them.
Iterate: next-most-changed rules follow the same pattern. Over 2-3 years, the COBOL adjudication engine shrinks module by module. Mainframe remains SoR for payment processing — that's not where the pain is.
Related capabilities, agencies, vehicles, insights
- Capabilities: Cloud Migration, API Design, Microservices, Data Engineering, Full-Stack Development.
- Agencies: IRS, SSA, VA, USDA, DoD, Treasury.
- Vehicles: SBIR, TMF, GSA MAS.
- Insights: Strangler-fig in federal, LLM-assisted COBOL translation, Why big-bang federal rewrites fail.
- Case studies: SAMHSA production ML (confirmed PP).