This engagement modernizes one subsystem of the ACAS platform — the Payment Processing module that handles supplier disbursement, cash posting, cheque writing, BACS issuance, and remittance generation — rather than rewriting the whole 1.36 million-line accounting system at once. The chosen subsystem is rebuilt on a current language runtime (Python with FastAPI), a modern user interface (React, replacing the 80×24 terminal), and a cloud-native hosting platform (AWS ECS Fargate); the rest of the application keeps running on COBOL unchanged. The modern subsystem operates side-by-side with the legacy via the SAROC coexistence bridge (Snapshot and Replay Ordered Cutover), and as subsequent subsystems follow the same pattern, the COBOL footprint shrinks one piece at a time until the modernization is complete. Subsystems are picked by combining business-functionality boundaries with technical boundaries so each modernization is small enough to ship safely but large enough to deliver visible business value — three independent agent runs converged unanimously on Payment Processing as the right first slice.
NUMERIC and ISO 8601.
ACCEPT/DISPLAY → React SPA + REST APIs. Responsive; live MOD-11 supplier validation; live appropriation preview before commit.
oi-b-nos * 1000 + oi-b-item preserved; OCCURS-array row caps replaced by child tables.
payment, open_item, batch_control, gl_posting, payment_audit); GL postings are written inline in the same DB transaction as the payment appropriation.pay.dat, openitm5.dat, purchled.dat), a translator maps them to sage-domain-event-v1 JSON, and RabbitMQ delivers them to a background-thread consumer inside payment-batch with natural-key idempotency.pl08x-pl9xx, sl08x-sl1xx, common/payments*), ~14,500 lines, three watched ISAM files, four cross-subsystem integration points (GL, Supplier Management, Customer Management, Purchase Order Processing).acas000–acas015 handlers is already a clean coexistence seam.payment-api + payment-batch + payment-reporting) on FastAPI / SQLAlchemy 2.0 / PostgreSQL 16; preserve every business rule; validate against real test data; wire OpenTelemetry, structlog, and the SAROC consumer.
acas.legacy.* events from RabbitMQ. Legacy COBOL operators keep using pl080–pl960 unchanged; the modern UI runs in parallel with read-only access. Compare outputs row-for-row.
Concho read the entire ACAS codebase — 1,358,687 lines across 449 COBOL files — and extracted a complete inventory of business rules (308 system-wide, 10 specific to Payment Processing), architectural elements (56 aggregate roots, 37 bounded contexts, 136 integration points), and platform constraints (197 cataloged at the system level). From that inventory, it derived 10 formal behavioral rule specifications with Given-When-Then scenarios, mapped 7 target tables to the legacy copybooks, and selected the SAROC coexistence pattern by matching the legacy interaction surface (green-screen terminal, no HTTP request path to fork). Every claim in the analysis was then verified: 12 of 12 sampled factual assertions were checked against the actual COBOL source via Concho MCP, with 0 hallucinations found; 11 of 11 Mermaid diagrams passed syntax checks; 0 cross-section inconsistencies after one iteration of targeted fixes.
The analysis runs in hours, not months. The full modernization report — legacy architecture analysis, target architecture design, platform-affinity scoring, business rule catalog, code translation examples, data mapping strategy, UI transformation examples, service architecture, and the strangler-fig cutover plan — was generated in approximately 14 hours of orchestration including a 3-perspective consensus for both subsystem selection and service decomposition. Comparable manual analysis is estimated at roughly 30 weeks. This speed comes from Concho’s pre-built Language-Agnostic Deep Scan, which provides 100% codebase coverage versus the 20–30% sampling typical of manual reviews.
This report is not the end of the process — it is the input to a companion agentic code generation workflow that turns the architectural guidance, schema decisions, business rule specifications, and UI transformation patterns documented here into runnable implementation artifacts: FastAPI services, Pydantic v2 entity models, SQLAlchemy 2.0 repositories, Alembic migrations, React UI components, PostgreSQL schemas, RabbitMQ topology, the SAROC coexistence bridge, Dockerfiles, ECS task definitions, Terraform / CloudFormation IaC, and CI/CD pipelines.
The code generation workflow uses a BDD/TDD iterate-till-green approach: it generates code from the behavioral rule specifications (Given-When-Then), writes automated tests derived from those specs, executes the full test suite, and — if any test fails — identifies the discrepancy, corrects the generated artifact, and re-runs until all tests pass. A human never reviews a broken artifact. Only when the modernized subsystem passes all behavioral, integration, and smoke tests does the workflow present it for human review. It does not arrive and get polished — it arrives already verified.
Five legacy 80×24 terminal screens rebuilt as React components against the FastAPI services. Each screen below is derived from the actual COBOL source code discovered via Concho — same fields, same business rules, modern interaction. The fifth panel is the Payment Cycle Workbench: a single SPA page that consolidates data from five separate legacy programs (pl080 entry, pl090 proof, pl100 cash post, pl940 cheque run, pl960 remittance) that were never visible together on the green-screen terminal.