@clacke @petecorey I don't have any principles formulated, but I usually just model data migrations as tasks (rake, mix, custom built triggered from admin panel...).

Even with regular migrations during the deploy you have a timeframe when the migration is already run, but you're still serving old code (with large codebases it's non-negligible amount of time). So I have a rule that migrations need to be compatible with old and new code anyway.

So you
1. Deploy schema migration
2. Run data migration
3. Deploy new code that relies on migrated data

Of course I can imagine situations where this does not cut it, but it works most of the time for me.