Refactoring a growing system while maintaining bug-for-bug compatibility is extraordinarily hard. Most people I know who've gone through such a migration never want to do it again.

Most people are simply bad at migrations.

Wasn’t Facebook built on MySQL with the friend graph written in relational SQL and PHP? The idea was but out and then perfected later. In my head this is the same as doing it on AWS or GCP fully on their proprietary stack and then once making some coin you start a refactor or a migration in parallel to your own hardware and stack as costs warrant it.

Dropbox is famous for doing this when they did their move from S3 to pocket — an in house storage layer they built.

It's not likely your product will have enough financial success to afford the huge amount of engineering effort facebook has put into improving their platform. If your system falls apart before you are making enough off of it to fix it you're going to just run out of runway.

Or to add to that, there are often very good reasons to optimize well before facebook did. The sheer friction of making the transition to The Right Thing can often be too difficult to overcome.

Ultimately, building a maintainable system requires that you allow for people being bad. If 10 smart engineers contribute to your system, and they each assume future developers will be good in their own distinct way, the resulting system will be so complicated that none of them are good enough to maintain it.

Preferably, everything that can be is loosely coupled and extensible.

If most are bad at migrations then what should most do?

Learn how to do migrations well. There's plenty of literature on the topic.