Many organizations that built applications 10-20 years ago had a very data-oriented approach to application architecture. Although mainly due to the particularities of Oracle-based systems, it became commonplace to couple the application to the database. (In the case of Oracle-connected applications, stored procedures and triggers coupled the database to the application.)
But what seemed like a good idea then causes a huge issue now when you move those applications and data to the cloud and want to leave the expensive legacy databases behind.
This architecture issue is not easy to fix after the fact. Indeed, you'll need to do some major surgery on the application to fix the underlying coupling issue. It's an expense that many enterprises are not willing to take on, yet it could be more expensive to continue on the current path.
The fact is that if you couple your application to your database, you're limiting your options for running on future platforms, not just those that are cloud-based. Moreover, it's just a bad idea because applications that are decoupled from the database perform better are easier to use in a multitenant system, and they can switch to a different database if needed later.
But most of that wasn't a consideration or issue a decade or so ago when database-coupe applications were the norm in IT. So what do you do now?
First, make sure you never, ever couple your new or refactored application to a database. No matter if it's proprietary or open, it's rarely a good idea. Enough said.
Second, look into what it would take to decouple the database from your current applications. This means rewriting stored procedures and triggers, but doing so may make good economic sense if it lets you move the applications to a public cloud.
I'm running into this issue more and more as I help enterprises migrate their applications to the cloud. The largest limiting factor is not the technology used at the time, but the application architecture itself, part of decisions made many years ago.
You can't go back and undo the past, but you can be sure not to repeat what has turned out to be a mistake. And in some cases you can fix today what you built in the past.