A good rule around "down" migrations

The concept of a "down" migration is surprisingly controversial in the Laravel community. Some developers go so far as to update the migration stubs to not even include the down() method at all. Their thinking is that rolling back a migration is just a bad idea in general. Instead you should "roll forward" with a new migration.

This tip isn't to argue against that point of view, but instead to address those who are writing down migrations and clarify a rule we enforce around when it is appropriate to run them.

Let's set up an example scenario with an application that has a system for roles and permissions. You're writing a new migration that introduces a completely new role and several new permissions. The down method in that migration removes the role and permissions, as you would expect.

Now let's say you deploy this and immediately the system starts throwing tons of errors. You decide it's best to roll back immediately. Hooray for down migrations, right?

In my experience, this scenario is hopefully extremely rare. What is more likely is that days or weeks later, you notice something more subtle happening that you didn't expect. What do you do now? Would you still roll back that migration?

I say "No!", that would be disastrous. What's the difference? It's the time that has elapsed. If days or weeks have gone by, all sorts of users may have been assigned to those roles and permissions. So now rolling back would become much more complex, and would destroy data.

So our rule in regard to down migrations in production: only run them within at most a few minutes of the deployment. Beyond that timeframe, you should write a new migration to fix the problem.

Here to help,

Joel

P.S. If you want to hear additional reasons why we write down migrations in our Laravel apps, we discussed this in more detail on our podcast.