Do we still need Down migrations? Taylor says No.

On the last episode of Laravel Podcast, Taylor Otwell said something controversial but I had a gut feeling about it for a long time. So, do you actually use down() method in migrations, and rollback them?

In fact, there are two problems.

First, that people don’t actually test down migrations. Developers tend to think only forward, feeling excitement to create new project but often forgetting about rollbacks.

It’s like some people have a backup of the database but never actually tried to perform a restore from that backup (remember GitLab story?).

So I’ve seen quite a few projects where developers write down() migrations but never actually care about whether they work.

* * * * *

Problem no.2 is a question – do we actually need Down migrations? Are those rollbacks the right way to fix some screw up? This is what Taylor said about it.

My view on that recently, in a past year, has been that you just never rollback. Ever. You would always go forward. Because I don’t know how you roll back without losing customer data. At least for my own projects like Forge or Envoyer, I could never really guarantee that I wasn’t losing data, so I think if at all possible, what I would try to do is write an entirely new migration that fixes whatever problem there is, and it would just migrate forward.

Sometimes, if it’s low traffic, and you feel pretty certain that no one’s messed with the new database schema, then probably you could just roll back, but..

I’ve actually stopped writing down() methods in my migrations entirely, recently, now that it’s optional. But it’s really mainly feasible in Laravel 5.5, cause you have the new db:fresh method which just totally drops all tables without running down methods.

So, if Laravel creator himself doesn’t use it, why should we?
You can also listen to the thoughts on migrations and rollbacks by Matt and Jeffrey on the original podcast from 30:18 minute.

Off-topic: by the way, do you know any other active Taylor in Laravel community? I keep mentioning full name, sometimes with link to Twitter, but I think we’re at the point where I just say Taylor and everyone know who am I talking about? ๐Ÿ™‚

Like our articles?
Check out our Laravel online courses!


  1. I confess that write `down()` methods in all of my migrations files; Also use this in the dev environment when the application is not running on production env, but when the things come real, I mean, when the real data becomes to the DB, I never use a rollback to any real situation;

    Like Taylor as sad, in the most of the times, we simply drop the database and restore a backup after writing some new migration to fix the problem;

    BUT… I think that the `down()` methods are most useful at the first steps of development and in Sandbox environments too.

    Off-topic: Yes, we know Taylor ๐Ÿ˜‰

  2. The problem is that you need way to rollback if migration failed only, but then rollback doesn’t work at all and leaves even bigger mess than broken migration did so… it doesn’t seem to make any sense to have them

  3. You need a down migration if you’re going to use database seeding in development. I constantly do artisan migrate:refresh –seed.

    As Gabriel Piccin wrote, I can’t imagine rolling back a production database, so once we go to production, all database changes will be proper alter table or create table, and we won’t need down migrations.

  4. Agree with everyone above. Useful in a dev environment, especially if I’m developing off the cuff and realize I forgot a column, or decide to change one. With no data in the new table, I just rollback, tweak my migration and migrate again. Here’s hoping that doesn’t go away. If it does, I’ll have a bunch of migration files ๐Ÿ™‚

    Ok, yea, I could plan a little better, but if I’m whipping up a prototype or just want to try something, it’s quite useful.


Please enter your comment!
Please enter your name here