Why legacy modernization fails in discovery, not in coding

The specification is the code

Every modernization program starts with the same sentence in the statement of work: the new system shall preserve the business behavior of the existing system. Nobody can point to where that behavior is written down. The original analysts retired, the requirement documents describe the 1994 release, and the change tickets since then live in three different tracking tools, two of them decommissioned.

So the only complete specification is the source. A loan servicing core with 2.4 million lines of COBOL, 1,100 copybooks and 600 JCL jobs is not documentation anyone can read in the time a program allows. Discovery becomes a sampling exercise: architects read the programs they believe matter, interview the people who remain, and write a requirements baseline that is mostly right.

Mostly right is the problem. The rules that were missed are not random. They are the ones buried in error paths, in WHEN OTHER branches, in a paragraph reached only through a GO TO DEPENDING ON index that nobody traced. They are the edge cases that surface in parallel run, or worse, after cutover.

Three ways discovery breaks

Across core banking and insurance programs, the same three failure modes repeat, regardless of the target stack or the integrator.

1. Incomplete rule inventory. The requirements baseline lists the rules people remember. The fee waiver for accounts opened under a 2003 promotion code is not one of them, because it is a single IF inside a 900-line paragraph.
2. Wrong service boundaries. Teams draw microservice boundaries from the org chart or the screen flow, then discover that two programs share a VSAM file through a copybook with a REDEFINES overlay, and that splitting them requires a data contract nobody designed.
3. No way to prove equivalence. Without an inventory of rules tied to source lines, testing reduces to comparing outputs on whatever data the team could extract. Gaps in the data become gaps in the proof.

Each of these is a discovery defect. None of them is fixed by a better build team or a faster framework.

What the public numbers say about the scale

The scale of the problem is documented even where failure rates are not. The US Government Accountability Office reported in GAO-16-468 that about 75% of the federal FY2015 IT budget went to operating and maintaining existing systems. CISQ estimated accumulated software technical debt in the United States at about $1.52 trillion in its 2022 report. A Vanson Bourne survey for Micro Focus in 2022 put COBOL in daily production use at roughly 800 billion lines.

When migrations go wrong, the consequences are public. The UK FCA and PRA fined TSB a combined £48.65 million in December 2022 over its 2018 platform migration. The regulators' findings centered on governance and testing of the migration, which is exactly where an incomplete understanding of the source system turns into operational risk.

We cite those figures and nothing more. Plenty of modernization failure percentages circulate in vendor decks; most cannot be traced to a methodology, and we do not repeat them.

Making discovery an engineering artifact

The fix is to treat discovery as compilation rather than reading. A compiler does not sample. It parses every program, resolves every symbol, and knows the type and storage layout of every field. If you build the same structures for analysis, an abstract syntax tree per program, a symbol graph across programs, copybooks and JCL, and control-flow and dataflow graphs on top, you can ask questions with complete answers.

• Which programs write LN-ACCRUED-INT, through any alias?
• Which branches assign a value to the fee field, and under what conditions?
• Which JCL steps run a program whose return code gates the month-end posting job?

That is what PYD ENTERPRISES does. The deterministic engine accounts for every executable path: extracted as a business rule, classified as plumbing (logging, I/O, error handling), or flagged for review. The output is a rule inventory where each rule is a DMN 1.5 decision table row or a formula, linked to the file and line range it came from, and an interface layer described in OpenAPI 3.1.

1{
2  "rule": "FEE-WAIVE-PROMO-2003",
3  "kind": "decision",
4  "decision": "MonthlyMaintenanceFee",
5  "source": { "file": "DDAFEE01.cbl", "lines": [412, 431] },
6  "inputs": ["ACCT-OPEN-PROMO", "ACCT-OPEN-DATE"],
7  "status": "needs-review",
8  "reviewer": null
9}

People still sign the rules

Automation does not remove judgment from discovery. It moves judgment to where it belongs. Instead of spending months finding rules, your business analysts spend weeks deciding which extracted rules are still policy and which are fossils from a product discontinued in 2009. The sign-off view puts each rule next to the source lines that implement it, so the conversation is about intent rather than archaeology.

In PYD ENTERPRISES' own engagement benchmarks, manual discovery costs $0.40 to $0.75 per line of code, and compressing a discovery phase from about nine months to about three weeks is typical. Those are our figures, measured on our engagements, and the larger saving is harder to put on a slide: the build team starts from a rule inventory they can test against.

Where to start

If you are scoping a program now, pick one system with a clear owner and a business process you can test end to end. Run a full parse before you write the statement of work, and price the build from the rule count and the review backlog rather than from lines of code. The ROI calculator gives a first estimate, and the anti-patterns catalog lists the constructs that most often hide rules.