You have full control over your migrations, you could just have a migration for 'users' and do all the user stuff in it.

The problem I see here is the problem that migrations solve, if you want to roll back one thing you'll have to roll back a lot more.

This is pretty simple as long as you aren't doing it for a production database (because it requires we reset the migrations, therefore wiping out any existing data):

1. Run "php artisan migrate:reset" - rolls back all migrations
2. Combine your migrations as necessary
3. Delete redundant migration files
4. Run "composer dump-autoload"
5. Run "php artisan migrate"

Sorry for refreshing this old topic, but we have around 400 migrations. Going over all of them would be really time-consuming (same goes for creating new migrations depending on the database status). Doctrine has this nice way of handling those, but how do that in Eloquent?

I've been thinking about this lately since I have the same problem. I think we would have to extend artisan migration to do something like artisan migrate:capture which will create one migration file that contains all your database schemas. Then you wipe out the rest of the files.

Is there any follow up on this? How did you guys handled it?