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? :)
Enjoyed This Tutorial?
Get access to all premium tutorials, video and text courses, and exclusive Laravel resources. Join our community of 10,000+ developers.
Recent Courses
Course
5 lessons
[NEW] Laravel Coding with AI Agents: Cursor, Claude Code, Codex
Course
16 lessons
Laravel Modules and DDD
Course
11 lessons
NativePHP: Build Mobile App with Laravel
Comments & Discussion
No comments yet…