I had a brief exposure to a COBOL application and started to understand some of the technical hurdles that make this hard and largely lead to 'big system replac

I had a brief exposure to a COBOL application and started to understand some of the technical hurdles that make this hard and largely lead to 'big system replacement' type projects which are extremely high-risk. If you've ever worked a VisualBasic Application, you'll have some inkling of what COBOL is like. One of the core things I saw with COBOl was strong coupling of application and data persistence. Further, where modern apps take a stateless approach for say a single API call, many COBOL application predate this concept. So not only are application and persistence coupled, the applications are VERY stateful. This makes replacing a 'piece' of the application extremely difficult as there is a lot of shared state to tease out of the system. Nor can you start building a second system that owns some piece of the data model, as COBOL's persistence models aren't built for shared write activity that a normal DB facilitates. You are forced to still write through the COBOl data model. Clearly not impossible, just difficult.