Stop writing data migrations
15.09.2025
Reading time: 2 min.
As many of us, I was writing data migrations as a part of database schema migrations.
Why that’s a bad practice, and what’s the better way to do this.
- Your data migration typically comes along with changes to schema. Do you have the data migration together with schema migration?
- If your data processing fails in the middle of migration, what’s the way to resume it?
- Do you ever need it again? I.e. does it make sense to keep this migration in migrations history?
If you tick at least two checks, congrats, you don’t have to keep data migrations with schema migrations. Just write a script, execute it and throw away!
Example for Rails migration
The task is to add rich texts replacing some plain text fields.
Migration from the plain text fields to rich text fields with ActiveText. How?
- Create a migration to add action_text_rich_texts table.
- Create a migration to rename old column containing plain text to the field prefixed with old_
- Write a rake task to convert the data from old column to the new place.
- Write a migration to remove old content after everything went smooth
Steps 1-2-3 are done within a single new PR. Once the schema is in the new state, rake tasks can be executed for data movement.
The subsequent PR just tears down old fields and voila.