Migration guide
Go suits small, explicit services, which is the opposite of a 9,000-line COBOL program. This guide shows how to cut the program into decisions and contracts first, and which COBOL semantics Go handles differently.
By Pranav Kulkarni, Head of Language Engineering · Updated 15 Oct 2026
Technical syntax challenges
float64 cannot represent 0.10 exactly. COBOL fixed-point fields need a decimal library or scaled integers (cents as int64) with the scale taken from the PIC clause. The spec has to state scale and rounding per field so every service makes the same choice.
EVALUATE TRUE takes the first matching WHEN. Go's switch with no tag behaves the same, but teams that turn the table into a map lookup lose the ordering. The extracted decision uses hit policy FIRST to make the order explicit.
COBOL checks FILE STATUS values like 23 (record not found) and SQLCODE +100 after each call, often routing several codes to the same paragraph. Each distinct business outcome should become a typed Go error or result, and the spec lists which codes lead where.
COBOL programs assume one task owns WORKING-STORAGE for the whole run, so values from a previous record can leak into the next one when a field is not reset. In Go, handlers run concurrently and must not share that state; the spec flags fields that carry over between iterations.
GO TO 3900-EXIT inside a PERFORM range and GO TO ... DEPENDING ON jump tables are flattened by the control-flow graph into explicit branches, which map cleanly to early returns in Go.
Extraction workflow
The sequence a PYD ENTERPRISES Discovery Scan runs for this stack. Every output links back to source file and line range.
Ingest the COBOL programs, copybooks and called subprograms behind the business capability you want as services.
PYD ENTERPRISES builds the control-flow graph through GO TO, PERFORM THRU and EVALUATE, and flags WORKING-STORAGE fields read before being set in a loop iteration.
Rules are grouped by the data they read and write; clusters with few shared fields are proposed as service boundaries.
Each EVALUATE and nested IF cascade becomes a DMN 1.5 table with hit policy, scale and rounding recorded per output.
Copybooks become JSON Schema and candidate operations become OpenAPI 3.1, so Go structs and handlers can be written or generated by your team from standard tooling.
Boundary fixtures are exported as JSON; Go teams load them in table-driven tests and run them in CI against each service.
Legacy in, specification out
Left: the COBOL construct as it sits in production. Right: the reviewed artifact your Go microservices engineers build against. PYD ENTERPRISES produces the spec and the tests; your team writes the service.
LEGACY SOURCE
1 3000-WIRE-FEE.2 EVALUATE TRUE3 WHEN WR-INTL AND WR-AMOUNT > 500004 MOVE 45.00 TO WR-FEE5 WHEN WR-INTL6 MOVE 35.00 TO WR-FEE7 WHEN WR-SAME-DAY8 MOVE 25.00 TO WR-FEE9 WHEN OTHER10 MOVE 15.00 TO WR-FEE11 END-EVALUATE12 IF CUST-PREMIER13 COMPUTE WR-FEE = WR-FEE * 0.514 END-IF.
EXTRACTED ARTIFACT
1{2 "decision": "WIREFEE-01 Wire transfer fee",3 "hitPolicy": "FIRST",4 "source": "WIREFEE1.cbl:412-426",5 "fixtures": [6 { "in": { "intl": true, "amount": "50000.00", "premier": false }, "out": { "fee": "35.00" }, "rule": "R2" },7 { "in": { "intl": true, "amount": "50000.01", "premier": false }, "out": { "fee": "45.00" }, "rule": "R1" },8 { "in": { "intl": true, "amount": "50000.01", "premier": true }, "out": { "fee": "22.50" }, "rule": "R1+P" },9 { "in": { "intl": false, "sameDay": true, "premier": true }, "out": { "fee": "12.50" }, "rule": "R3+P" },10 { "in": { "intl": false, "sameDay": false, "premier": false }, "out": { "fee": "15.00" }, "rule": "R4" }11 ]12}
Architectural best practices
In depth
A typical online or batch COBOL program mixes validation, pricing, posting and reporting. Go services work best when each does one of those, with a clear contract. That split needs evidence: which fields does each rule read, which records does it write, and which rules always run together. PYD ENTERPRISES' rule clustering gives you that evidence with source links, and architects decide the final boundaries.
PYD ENTERPRISES does not generate Go code. It produces DMN tables, JSON Schema and OpenAPI contracts and JSON fixtures. Many Go teams generate structs from the JSON Schema with their usual tools and write handlers by hand against the decisions.
The condition is WR-AMOUNT > 50000, strictly greater. A transfer of exactly 50,000.00 is charged 35.00, not 45.00. The fixture generator reads the comparison operator and the field's scale (S9(9)V99, so the next representable value is 50000.01) and emits fixtures on both sides of the boundary. Off-by-one-cent errors at thresholds are among the most common defects after a rewrite, and these fixtures catch them before production does.
FAQ
No. It produces decisions, contracts and fixtures. Your engineers write the Go services, often generating structs from the exported JSON Schema with standard tools.
Use a decimal library or scaled integers consistently. The spec records each field's digits, scale and rounding, so whichever choice you make can be tested against the fixtures.
Yes. The same fixtures can drive the legacy program through a test harness on the mainframe or a compatible runtime, which confirms the fixtures themselves before the Go service is tested.
Request a codebase scan and review extracted rules, contracts and fixtures for your own COBOL estate, inside your VPC.