The bank wanted to modernise the batch system that calculates overnight interest. Three teams had already failed to scope it. The fourth tried PeaCOBOL and got, in one afternoon, the module inventory, the data flow, and the exact point where rounding errors were introduced.
That report became the scoping document. The migration plan — written from a machine-generated map of the code — shrank from nine months to six. The bank didn't have to hire a COBOL expert, because the tool answered the questions the board kept asking.
The lesson isn't that PeaCOBOL replaces understanding COBOL. It's that you shouldn't have to understand 40 years of legacy code just to make a plan. Machine-readable inventory first, then decide what to keep, what to replace, and where to draw the boundary.