The key question is whether you have behavioral evidence, not just documentation or code comments. If you can run both the old and new systems with the same inputs and compare outputs, you can confidently preserve and migrate the logic, as you have a method to detect any differences. In this case, understanding the original intent is less critical if empirical equivalence can be verified.
Migration is an opportunity to address these questions, but only if teams are willing to pause and examine them, rather than using “we can’t explain it” as justification to carry logic forward unchanged.
In reality, most teams make this decision too quickly and often default to preservation because it feels safer. However, preserving logic that is not understood does not reduce risk; it merely shifts it. The uncertainty moves from COBOL to Java, and the advantage of a proven mainframe environment is lost.
If behavioral equivalence cannot be established due to environmental factors, stateful logic, or inaccessible data, it is important to reassess whether the business rule implemented by this logic is still relevant. Often, the logic may reflect outdated regulatory requirements, obsolete products, or workarounds for systems that have since been replaced.
