Where business rules hide in COBOL
A COBOL program rarely announces its business rules. A payment cutoff, a validation on a policy number or a compliance check is usually a few lines of IF logic inside a paragraph, sitting between file handling and report formatting. The original authors are often gone, and the documentation is missing or wrong. That is the situation behind most stalled COBOL modernization projects: teams spend months working out what the system does before they write any new code.
The rules tend to cluster in a few places:
- Payment and posting logic: amount limits, rounding, cutoff times, fee calculations
- Validation paragraphs: field checks, cross-field edits, rejection codes
- Compliance logic: sanctions and threshold checks, reporting triggers, audit fields
- Copybooks and shared subprograms, where one change affects many callers
- JCL and scheduler settings, which decide when and in what order rules run
The last two are the ones teams miss. A rule that looks simple in one program may be overridden in a called module or only fire in a nightly batch step.
Manual extraction: what it takes
The manual route starts with an inventory: every program, copybook, JCL member and the data files each one touches. From there an analyst reads the PROCEDURE DIVISION, follows PERFORM chains and CALL statements, and writes each rule down in plain language, with the program name and paragraph where it lives.
This works, and it is how a lot of discovery has been done. It also has real limits. It needs someone who knows both COBOL and the business, which is a shrinking pool. It is slow on large estates, and two analysts reading the same program can describe the same rule differently. Dead code is another trap: paragraphs that no longer execute look just as authoritative as live ones, and teams end up documenting rules the business stopped using years ago.
Manual reading is still the right tool for a small set of high-risk programs, such as a core payment engine. For everything else, it helps to have a first pass done by something faster.
AI-assisted extraction
AI-assisted tools read the code at scale and propose rules for people to review. They trace data through the program, connect a calculation to the fields it uses, and describe the logic in business terms instead of COBOL syntax. Our overview of how AI agents read legacy code explains the mechanics, and the broader legacy code analysis guide covers how this fits into discovery.
Replai's platform maps the business meaning inside legacy codebases so a modernization team can see what they are working with before they touch anything. The useful output is not a translation of the code. It is a list of candidate rules, each tied back to the source lines that implement it, so a reviewer can check the claim against the code.
Treat the output as a draft. An AI-generated rule is a hypothesis until someone who knows the business confirms it. The speedup is real, but it moves the work from reading code to reviewing findings, not to skipping review.
Validating rules with subject-matter experts
Validation is where extracted rules become trustworthy. Bring the rules to the people who own the process: payments operations, underwriting, compliance, finance. Keep the sessions short and concrete.
- Present each rule in plain language with a worked example, such as a specific amount or policy type, instead of showing code.
- Ask whether the rule is still correct, was changed by a workaround, or is obsolete.
- Record disagreements. When the code and the expert differ, find out which one reflects what actually happens in production.
- Check against real data. Run sample transactions through the existing system and confirm the documented rule predicts the result.
Expect surprises. Some rules exist only because of a regulation that has changed. Others are undocumented exceptions that a single team relies on every day. Finding these before migration is far cheaper than finding them in testing.
Documenting rules so they survive the migration
A rule that lives only in a spreadsheet will be lost within a year. Document each one in a consistent format that your migration team, testers and auditors can all use:
- A short plain-language statement of the rule
- The source program, paragraph and copybook it comes from
- Inputs, outputs and any related data fields
- The business owner who confirmed it, and the date
- At least one test case with expected results
Those test cases matter most. They let you prove that the new system, whether you follow a COBOL to Java migration or another path, behaves like the old one. Keeping the rule catalog current after go-live also supports the wider goal of legacy system knowledge transfer, so the next team does not start from zero.
Frequently asked questions
Where are business rules usually found in a COBOL program?
Most sit in the PROCEDURE DIVISION as IF and EVALUATE logic, often inside validation and calculation paragraphs. Copybooks, called subprograms and JCL or scheduler settings can also change how a rule behaves, so they need to be reviewed too.
Is manual or AI-assisted extraction better?
Manual reading suits a small number of high-risk programs where an analyst needs full certainty. AI-assisted extraction is faster across a large estate, but its output is a draft that subject-matter experts still need to confirm.
Why do extracted rules need review by subject-matter experts?
Code shows what the system does, not whether the business still wants it. Experts can confirm a rule is current, flag workarounds and identify logic that is obsolete.
What should a documented business rule include?
A plain-language statement, the source program and paragraph, inputs and outputs, the business owner who confirmed it, and at least one test case with expected results.
Can we start migrating before the rules are extracted?
It is risky. Teams that skip discovery often hit scope surprises later, and critical rules that stay buried can be lost in translation to the new system.
How does rule extraction connect to testing the new system?
Each documented rule with a test case becomes a check that the migrated system produces the same result as the original. That gives you evidence of equivalence instead of relying on assumptions.