I'm not a fan of this idea after seeing it implemented in several projects for several years. I've seen projects not being developed to their full potential just because people spent an absurd amount of time trying to keep themselves away from the Framework.
If the Business is expecting the application to grow and they do not want to be tied to a specific Framework, it's better for them to create their own framework in the first place... one that they can control, that's able to grow with the requirements.
Bear in mind that most of the times there is just not enough time or resources to make the perfect architecture from scratch. That's when you want to use a Framework. You let the Framework make standards and take the decisions on how your code should be structured. Only when you recognize this and start to code following the Framework Conventions, you will be truly reaping the benefits of the Framework.
When you find the troubles that you're speaking about (painful migration), I believe it's more related to the way you make your own code than the Framework itself. This post in Reddit explains it better.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.