COBOL Migration Risks & How to De-Risk Them

Part 7 ended on a reassuring note — that you do not have to see every rule in advance, because parity validation catches what you miss. This part earns that reassurance by being specific about what can go wrong and what, exactly, catches it. A COBOL migration on a system that runs money is one of the highest-stakes pieces of work in enterprise software. The risks are real and well-understood; so are the practices that contain them. The teams that fail are rarely the ones who hit an unknown risk — they are the ones who skipped a known control.

The risks that actually sink COBOL migrations

These are the failure modes that recur, in rough order of how much damage they do:

Lost business rules. The headline risk, covered in Part 7: an undocumented rule — a rounding convention, a special case, a validation threshold — is dropped in translation. The migrated system passes its tests and is nonetheless wrong, in cases no one knew to check. On a ledger this is not a defect, it is an incorrect financial answer, and it typically surfaces only when a customer dispute or a regulatory review forces it into view. Its danger is its invisibility.

Decimal drift. The most preventable serious error. COBOL COMP-3 fields do exact base-ten arithmetic; map them to a binary floating-point type — double in Java, float in Python — and rounding errors creep into money. They are small per transaction, cumulative across millions, and they fail reconciliation while passing casual testing. Part 5 covered the fix: exact decimal types, scale and rounding matched per field. The risk is that one field gets missed.

Missed edge cases. The undocumented value concentrates in the rare branches — the record type handled specially, the once-a-quarter batch path. Testing with a clean, synthetic data set never exercises them, so they pass validation and fail in production when the real case finally occurs.

Data-conversion errors. EBCDIC-to-modern transcoding, REDEFINES, and OCCURS DEPENDING ON all make data migration error-prone. A field converted with the wrong picture, or a redefined layout read the wrong way, corrupts data silently — and corrupted data is harder to detect and costlier to unwind than corrupted code.

The big-bang cutover. The meta-risk that amplifies all the others. A multi-year rewrite that cuts over on a single date concentrates every one of the above into one irreversible moment, with no way back when something is wrong. Boston Consulting Group reported that up to 70% of digital transformations fail to deliver on their objectives (September 2023), and large all-at-once mainframe rewrites are the archetype of that statistic. The failure is structural, not a matter of effort: undocumented rules are discovered by breaking them in production, scope outruns the team, and the cutover offers no rollback.

Performance against the batch window. A modern slice that is functionally perfect but too slow to finish inside the overnight batch window is still a failure. Throughput is a correctness requirement on these systems, not a nice-to-have, and it has to be validated like any other behavior.

De-risking is structural, not heroic

The mistake is to treat these risks as things to be out-careful-ed — to believe that a sufficiently diligent team avoids them by trying hard. They are not avoided by effort; they are avoided by structure. The two properties that make COBOL migration dangerous are concentration (one big irreversible event) and invisibility (rules you cannot see until they break). Every effective control attacks one or both.

Migrate incrementally. Replace the single big cutover with many small ones. A slice is a coherent piece of business behavior, sized to ship in weeks, with the COBOL running the whole time. This directly defeats concentration: each step is small, and a problem in one slice is contained to that slice rather than threatening the whole system. The legacy-modernization series makes the full case in incremental vs big-bang modernization.

Run the modern slice in the shadow of the COBOL. Before it carries any live traffic, the rebuilt slice processes mirrored production data alongside the original. This attacks invisibility: real production data exercises the real edge cases, so missed rules and decimal drift show up in the shadow run rather than in front of a customer. This is shadow-traffic testing.

Prove parity against the live system. Compare the modern slice’s outputs against the COBOL’s — record for record, to the cent — and treat any discrepancy as a defect to be explained before cutover. Crucially, the comparison is against the running system, not the specification, because the running system is the only complete statement of correct behavior. This is reconciliation and output comparison, and it is the gate that catches lost rules and decimal drift directly.

Cut over gradually, with rollback at every step. A facade in front of the system shifts traffic to the modern slice incrementally — a small percentage first, then more as confidence builds — with the ability to route back to the COBOL instantly. This keeps every step reversible, so a problem that slips through parity testing is a quick rollback rather than a crisis. The COBOL program is decommissioned only after the modern slice has earned full live traffic.

Put together, these turn one irreversible bet into a series of small, reversible, evidence-backed steps. That is the entire game on a system that runs money: never be in a position where being wrong is both undetectable and unrecoverable.

The risk of doing nothing

It would be dishonest to frame migration as pure downside risk against a safe status quo, because the status quo is not safe — it just hides its risk better. A COBOL estate maintained by a bench that is retiring at about 10% a year (IBM, reported via Fujitsu, 2020) carries its own compounding risk: the knowledge decays whether or not you migrate, change gets slower and more dangerous, and the eventual migration only gets harder as the people who could validate it leave. The honest comparison is not “risky migration versus safe stasis.” It is “a controlled, reversible migration now versus a forced, knowledge-starved one later.” The first is a managed risk; the second is the one that actually sinks organizations.

Controls should scale to the stakes

De-risking controls cost real time and money, and on a genuinely low-stakes workload — a small, stable, rarely-changed program with no money or compliance exposure — the full apparatus of shadow running and per-slice rollback may be more than the risk warrants. The controls should scale to the stakes. But the instinct to skip them because a system “seems simple” is exactly how undocumented rules bite, so the bar for skipping should be high and deliberate. On anything touching money, records, or regulation, the controls are not optional.

Where this leads

The de-risking discipline is clear, but one part of it — recovering the behavior in the first place — has always been the slow, expensive bottleneck that makes migrations long and keeps them dependent on scarce experts. That is the step where AI genuinely changes the economics, and also the step where overclaiming for AI does the most damage. Part 9, AI for COBOL Modernization, draws the line precisely: where AI-accelerated discovery removes the bottleneck, where human judgment and parity validation remain irreplaceable, and how to tell an honest AI claim from a dangerous one.