Cleaning up old Rails migrations

Claudio B.
Clutter Developers
Published in
2 min readOct 24, 2018


After working on a Rails project for months, it’s not unusual to have hundreds of migration files in the db/migrate folder. Turns out, you can safely delete the ones that already ran in production, keeping your codebase small.

Migrations in Ruby on Rails are files that indicate an incremental change to apply to the database. Examples include creating a table, removing an index, changing the default value of a record, or adding a column:

After you write a migration file, you can run it locally by typing bin/rails db:migrate. In the example above, the migration will add a column called priority of type Integer to the table tickets on your local machine.

To apply the same change to the production database, deploy the migration file to the production server, then run the migrations there. With Heroku, for instance, that means typing heroku run bin/rails db:migrate or setting up a release process with that command.

Now that the incremental change has been applied both to your local and to the production database, there is no real need to keep the migration file around… except if you have co-workers! If you do, you should wait for all of them to run the migration before deleting the file.

My suggestion is to periodically delete migration files older than 3 months:

All migrations starting with 201710 were created in October 2017. They can be deleted in January 2018.

When you do that, also add a new migration with the same timestamp as the last migration you deleted, with the following content:

This migration takes care of co-workers who have not touched the app for 3 months, inviting them to reload the database schema before running further migrations.

Every other machine (including your local computer and the production server) will not try to run this migration, since it shares the same timestamp as the last deleted migration (20171027231859 in the example above).

Deleting old migrations is not a requirement for a Rails project, but it’s a good practice to keep your codebase small, helping developers find the code they are looking for when they perform “Find in project” searches in the project.

If you enjoyed this article, please share with your friends. If you are looking to join an amazing team of Ruby developers, check our current openings at Clutter.