Preserving Business Logic in a COBOL Migration

Every part of this series has circled the same fact from a different angle: the genuine value locked inside a COBOL estate is not the code, it is the behavior — the thousands of business rules that decades of edits have written into the programs and nowhere else. Part 4 named preserving that behavior as the real difficulty; Parts 5 and 6 showed that no choice of target language helps with it. This part is about the work itself: recovering the rules, capturing them, and carrying them across without loss. It is the most important part of the series, because getting it wrong is how COBOL migrations fail.

What “business logic” actually means here

When people say a COBOL program “contains business rules,” it sounds abstract. It is not. It is concrete, specific, and consequential:

• the exact rounding convention in an interest or premium calculation, and the regulation it satisfies;
• the special-case handling for a particular account, product, or record type — the IF branch added in 1998 for one edge case that turned out to recur;
• the validation rules that decide which transactions are accepted, rejected, or flagged;
• the sequence dependencies in batch — that this job must run before that one, because the second relies on a state the first produces;
• the tolerances and thresholds — what counts as a match, what triggers a hold, what rounds up versus down.

These are not implementation incidentals. They are the product. A bank’s lending system is its lending rules; an insurer’s policy engine is its underwriting and claims logic. Lose a rule in migration and you have not introduced a bug — you have changed what the business does, usually without anyone noticing until a customer or a regulator does.

Why the rules are undocumented — and why that is normal

The instinct of someone new to this is to ask for the documentation. There usually isn’t any worth trusting, and understanding why prevents a lot of false confidence. Over a system’s thirty- or forty-year life, every change was made under time pressure, applied directly to the code, and shipped. Updating a specification to match — if a specification ever existed — was the step that got skipped, every time, for decades. The result is that the running code is the only complete and accurate description of what the system does. Any document that predates it describes the system as it was imagined, not as it behaves.

This is precisely why rewriting “from the requirements” is a trap, and why Part 8 treats it as the leading cause of migration failure. The requirements are a historical artifact. The behavior is the truth, and the behavior lives in the COBOL and in the memories of the few people who have maintained it.

Extraction: reading the rules out of the code

Business-rules extraction is the disciplined recovery of that behavior into an explicit, reviewable form. Done well, it reads the estate as one connected system rather than program by program:

1. Read the code and its context together — the COBOL, the copybooks that define the records, the JCL that sequences the batch, and the data schema. A rule is rarely confined to one program; it lives in the interaction between a calculation, a record layout, and a batch dependency.
2. Recover the rules and their edge cases — not just the happy path, but the branches, the special cases, the error handling, the thresholds. The edge cases are where the undocumented value concentrates, and where rewrites most often fail.
3. Capture them as living specifications — artifacts that state, in reviewable form, what each rule is and where it lives: the calculation logic, the conditions, the data flows, the call graph. “Living” means owned and maintained by the team, not a one-time document that rots.
4. Validate them with the people who know — ideally the long-serving staff confirm the recovered rules while they are still available. This is the step the workforce clock from Part 3 is running against.

The output is not a pile of documentation for its own sake. It is the specification the migrated system is built and tested against — and, separately, an asset of real value even if migration is deferred, because it ends the organization’s total dependence on a few retiring people.

Where AI changes the economics — and where it does not

Reverse-engineering business rules from COBOL has always been the slow, expensive bottleneck of migration, because it depended on scarce human readers working through hundreds of thousands of lines by hand. AI-accelerated discovery changes that bottleneck specifically. It can deep-read the COBOL, copybooks, JCL, and schema together and draft the call graph, the data flows, the dependencies, and the candidate rules far faster than manual review — an analysis-time gain that takes the slowest step from months toward weeks.

What it does not do is make the result automatically trustworthy, and being precise about this matters for credibility. AI accelerates the reading and drafting; senior engineers and the remaining domain experts own the judgment — confirming which recovered rules are real, which are dead code, and which edge cases matter. And no amount of analysis proves the migrated system is correct. Only parity validation does that. Part 9 covers exactly where AI helps and where claiming more than it delivers would be dishonest.

Carrying the rules across without losing them

Recovery is half the job; the other half is making sure the rules survive the trip into the target language. Two disciplines hold:

• The specification drives the build, and the original drives the proof. The migrated code is built from the recovered specification, but it is validated against the running COBOL — not against the spec. A spec can be wrong; the live system, by definition, is what the business actually does. Comparing the modern slice’s outputs against the COBOL’s, record for record, is parity validation, and it is the only check that catches a rule that was recovered incorrectly or missed entirely.
• Edge cases get explicit attention. Because the undocumented value lives in the edge cases, parity testing has to exercise them deliberately — using mirrored production data so the rare-but-real cases actually appear, rather than a tidy test set that only covers the happy path.

This pairing — build from the recovered spec, prove against the live system — is what lets a migration preserve behavior it cannot fully see in advance. You do not have to have recovered every rule perfectly, because parity validation will surface the ones you missed before they reach customers.

The limits of extraction

Extraction has limits worth stating. Some “rules” turn out to be bugs the business has unknowingly depended on, and a migration has to decide deliberately whether to preserve a bug or fix it — a business decision, not a technical one. Some code is genuinely dead and should be recovered only far enough to confirm it can be dropped. And where the experts have already gone, recovery is slower and less certain, leaning harder on parity validation as the backstop. None of this changes the core discipline; it just means extraction requires judgment, not just tooling.

Where this leads

Preserving business logic is the central task, and the failure to do it well is the central risk. That risk has specific shapes — lost rules, decimal drift, missed edge cases, the big-bang cutover — and each has a corresponding gate that catches it. Part 8, COBOL Migration Risks & How to De-Risk Them, lays out the concrete failure modes of a COBOL migration and the practices — incremental slicing, shadow running, parity validation, staged cutover with rollback — that turn a high-stakes migration into a controlled one.