>Sunsetting is often a bug-for-bug type of conversion, because the output of COBOL programs are similar to database tables. Other programs are built on top of t

>Sunsetting is often a bug-for-bug type of conversion, because the output of COBOL programs are similar to database tables. Other programs are built on top of this data and that consumer code introduces a bunch of expectations on how the output of your replacement must behave to keep everything working. The number of consumer programs that have some expectation on the data can range from dozens to thousands. > So you can either read and understand and fix all the consumers as you make your replacement behave to spec instead of behaving identically, or you do what most sunset teams do and you make it produce identical output. So on point. And this problem exists not just in legacy systems built in COBOL. Also in much newer systems built with SQL in my line of work. The horror show I regularly encounter is a SQL function used in a production system that requires 50+ variables as input. 50+ fields as output. Any change in the order of the fields screws everything up. Makes me crazy.