Alternatively, write all the business logic in the database. This way you can better leverage the DB features and ensure that logic only needs to be written once.
It was a nightmare. Deployments were very difficult, there was little tooling, reasoning about the system was difficult, and of course running so much code in Oracle required very expensive licenses.
And it is much harder to hire hard core PL/SQL devs over Java, C#, Python or whatever.
You really don’t want significant code in the DB. It can be useful for some cases, like automating audit tables, but that is about it.
And for triggers - I feel for anyone maintaining business logic located in triggers. What a debugging hell that can be.
At one point Terradata claimed they had a tool that could auto convert to something else with 99% success rate, or something like that. The reality on our samples we tried was like 40%.
Plus, Pl/SQL code is often very “chatty” with the data, if you try to port it as is you will often suddenly see performance issues as you see the amount of data that has to be sent over the wire from the DB to your code tier.
I eventually left. We pivoted to a new product and leadership agreed the old system was legacy to remain untouched. Eventually this thinking changed and the old product was to be integrated with the new. Sprocs were back baby! My battle was lost, I was done.
Rather, lets rejoice with latest C#, zig, rust, PoweShell or whatever-beautiful-language-and-ecosystem-perfected-in-latest-decade we have, instead of horrible SQL.