If you are building software where the customer is the deployer being flexible on what database can be used is a pretty big step. Without it could turn off potential customers that have already existing infastructure.

Some of us have had to support multiple database targets. So I don't know about changing a database in a running application, but a good abstraction has made it easier to extend support and add clients when we could quickly and easily add new database providerz

Well, developing on SQLite and deploying to Postgres is a much more common scenario than migrating your data from one DBMS to another.

Working in a data intensive context, I saw such migrations very often, from and to oracle, ms sql, postgres, sas, exasol, hadoop, parquet, Kafka. Abstraction, even further than orms, is extremely helpful.

Unfortunately in most real case scenarios companies don't value abstraction, because it takes time that cannot be justified in PI plannings and reviews. So people write it as it is quicker, and migrations are complete re write. A lot of money, time and resources wasted to reinvent the wheel.

Truth is that who pays doesn't care, otherwise they'd do it differently. They deserve the waste of money and resources.

On the other hand, now that I think of it, I've never seen a real impacting OS migration. Max os migration I've seen is from centos or suse to rhel... In the field I work on, non unix OSes are always a bad choice anyway