With old systems the catches always seem to be knowing the deep hidden why's to the encoded business rules and all the bugs, not just the high level goals and basic code.
Older systems have tons and tons of business logic encoded in them to handle edge cases and those functions will be in odd places, and then downstream systems have tons of logic in them to handle (and expect) bugs that your original system has.
Saying "let's rewrite a System that does X" is fine, but you also need to know all the arcane business rules and weird bugs in the system that aren't nicely spelled out in docs, or requirements, or some config file, but are nested deep deep inside in the app, hidden in unexpected places. The complex interactions of these functions generates the complexity, not just "Cobol". 50 years of rushed additions of weird rules to handle years past incidents or business logic changes.
Especially with old finance, insurance, and other systems that have this sort of longevity the original people who knew the why's have long since left. Any attempts to optimize, fix rules, fix bugs etc will produce a beautiful new clean system that's performant and simple and doesn't work at all.
A good re-engineering of any legacy system starts with logging. Reading code is simple, just use your eyes. But understanding what the code actually does requires knowledge of not just code but also data. The data that actually flows through the system on a regular basis and how it gets transformed from one function call to the next.
The next necessary step is piecemeal migration. You're not going to be able to process all request types from the get go. Start with building a new system that handles form A and leave forms B through Z to the existing system. The next project will be to tackle form B, and so on.
If either of these steps isn't possible (due to dysfunctional management, usually) then the project is doomed to fail.
The problem like assembler or god forbid vacuum tube based old system is those edge cases … hard to log them or eyeball them. Then once a year or certain event, the logic happened. Old system worked. Yours don’t. … sigh
Older systems have tons and tons of business logic encoded in them to handle edge cases and those functions will be in odd places, and then downstream systems have tons of logic in them to handle (and expect) bugs that your original system has.
Saying "let's rewrite a System that does X" is fine, but you also need to know all the arcane business rules and weird bugs in the system that aren't nicely spelled out in docs, or requirements, or some config file, but are nested deep deep inside in the app, hidden in unexpected places. The complex interactions of these functions generates the complexity, not just "Cobol". 50 years of rushed additions of weird rules to handle years past incidents or business logic changes.
Especially with old finance, insurance, and other systems that have this sort of longevity the original people who knew the why's have long since left. Any attempts to optimize, fix rules, fix bugs etc will produce a beautiful new clean system that's performant and simple and doesn't work at all.