Migrations are immutable. We run them once, and then they're done for good. The idea that migrations are reversible
- the "up" and "down" pattern that you find in, for example, Rails and Phoenix - is not something you should build a workflow on. Rolling back migrations should happen only when you made a mistake in a migration & need to revert the database and it's data to a previous schema version.
When developers talk about database migrations, they usually mean database schema migrations, but they might also be talking about data migrations. To migrate the database schema and to reconcile the existing data to that schema are different tasks. In my 4 years of web development, I have seen data migrated within schema migrations, and I have also seen data migrated following schema migrations via data migrations. I haven't worked with a backend complex enough to have a glaring need for separating schema and data migrations. However, you might as well separate these two types of migrations. They are not the same task at all. One should happen before the other.
Data should be considered immutable from the point of database migrations. You shouldn't be rolling back data migrations. Data migrations are not supposed to seed your database. If you need to seed your database, use a seeds file or just grab a dump of the production/staging application, or use one of your database backs.