I'm not sure, actually. Running an application on such specialized application servers as Heroku provides has the benefit of being highly scalable, but it also means you have to adhere to some architectural patterns, which I believe address a lot of the migration issues people would normally encounter.
The most obvious example (and probably most relevant) is that on Heroku you can't store permanent files locally. Instead you need to store them on something like Amazon S3. However, the application servers also aren't a great place to do things like video processing. Instead, you'd lean on a third-party service like Zencoder.
As a result, applications that run well on Heroku have very few environmental dependancies and migration should be relatively straight forward. They even make it brilliantly easy to dump your database to a file that can be imported elsewhere.
I think the real pain in migrating from Heroku is outside of the application itself. I think the real pain is duplicating all the infrastructure and staffing you never had to think about when you deployed your app in the beginning. Honestly, I don't even know all the details of what they do. But I know I've never set it up myself and I'm not really interested in doing it. I don't want to hire someone to do it, either. It's enough being on call for application issues, never mind all the rest.
In every venture I'm involved in, traffic and users translate directly into money, so paying Heroku a cut of that success is not a problem. They've earned it.