Yes and no.
While a lot of ORMs offer this functionality and it usually works just fine when you actually have real production data you will most likely realize that this is just small part of the problem.
Ive been part of several projects for switching an app from database X to database Y during my career and even those projects that used an ORM was...painful. The main reason for this is that if you have spent time writing code for one database (say MSSQL) then even if you use an ORM you will end up structuring your data for what is fast and works good in that database. And when you later switch to something else, lets say PostgreSql, you will notice that...the same thing that is quick in MSSQL might be slow postgres, and vice versa.
The ORM cant help you with this. At some level, the ORM will probably even work against you when you try to solve this issue (since the ORM is a layer on top the SQL you will have a harder time actually finding the slow queries, figuring out whats wrong with them and optimizing them).
In my experience, the ORM helps you with the part that was already "easy" with a database switch. But for the part that is actually hard...you are on your own, and the ORM might even work against you.
With that said, consider your use case. How much data will you have? Why are you switching databases? What is your performance targets? For some apps, the things Im talking about it not something that you even need to consider in the first place.