In this post titled “laravel 12 rollback a specific migration” , I will show you how to rollback a specific migration in laravel 12 application, step by step with example.
This example works with laravel 7, laravel 8, laravel 9, laravel 10, laravel 11, and laravel 12.
In this example, you’ll learn how to:
- Rollback a specific migration
- Rollback and re-run a specific migration
- Rollback a specific migration with database seeding
In real-world there are situations where you might not want to rollback all migrations, but only a specific one. This is especially useful when:
- You made a mistake in a particular migration file and want to fix and re-run only that migration.
- You’re testing changes to a single table or feature and don’t want to affect the rest of the database schema.
- You’re debugging an issue related to a specific table structure or relationship.
Instead of running a full migrate:rollback, which reverts the last batch of migrations (possibly including multiple files), Laravel allows you to rollback a single migration file using the –path option.
php artisan migrate:rollback-- path=database/migrations/2025_07_14_134057_create_tests_table.php
🔔 Note: Make sure there’s no space between –path= and the file path. If you include a space, It will cause an error.
This command rollback only the migration located at the specified path. It’s important that the path matches the actual file name in the database/migrations directory.
Rollback a Specific Migration And Re-Migrate
Sometimes, you may need to rollback a specific migration and immediately re-run it—for example, if you’ve updated the schema or fixed an error in the migration file.
laravel provides –path option with migrate:resfresh to get the required result.
php artisan migrate:refresh --path=databse/migrations/2025_07_14_134057_create_tests_table.php
This command will Rollback the specific migration file. Instantly re-run the same migration.
This is extremely useful during development when you’re frequently adjusting a single migration file and want to test changes without affecting the rest of your database schema.
Read Also : Laravel 12 Create, Skip, Run and Rollback Migrations
Rollback a Specific Migration With Seeding
When working on a particular feature, you may want to rollback and re-run a specific migration along with database seeding—especially when your feature relies on seed data for testing or development.
Laravel allows you to achieve this using the migrate:refresh command combined with the –path and –seed options.
This command will:
- Rollback the specific migration.
- Re-run the same migration.
- Run the database seeders, such as DatabaseSeeder or any other seeders you’ve defined in it.
If you want to add recordes in database then run seeder by using –seeder option:
php artisan migrate:refresh --path=database/migrations/2025_07_14_134057_create_tests_table.php --seed
Seeding a Specific Seeder (Optional)
If you want to run a specific seeder instead of the default one, use the --seeder option:
php artisan migrate:refresh --path=database/migrations/2025_07_14_134057_create_tests_table.php --seed --seeder=UserSeeder
⚠️ Important:
- Make sure the path is accurate and there’s no space after –path=.
- The migration file must have been run before (i.e., it should exist in the migrations table), otherwise Laravel won’t be able to rollback it.
This is a powerful way to test and verify changes to a specific table along with fresh test data.
Read Also : Laravel 12 Print Last Executed Query with Parameters
Conclusion
Rolling back a specific migration in Laravel 12 is straightforward once the right flags are used, letting developers target a single file without affecting the entire schema batch. Using migrate:rollback with the –path option reverts only the specified migration file, while migrate:refresh –path allows immediately re-running that same migration after rollback, which is ideal when iterating on schema changes. Adding –seed to migrate:refresh helps reload essential test data in one step, streamlining development workflows. Community references also highlight related controls like batch-based rollbacks and practical caveats (such as avoiding spaces around –path=) that prevent common command errors and preserve database stability during iterative development.
Frequently Asked Questions(FAQs)
Q1: What’s the difference between batch rollback and path-based rollback?
Batch rollback (php artisan migrate:rollback) reverts the most recent batch of migrations as a group, while –path rolls back only the specified file regardless of what else ran in that batch. Path-based rollback is safer when the goal is to revert a single change without touching other migrations in the same batch.
Q2: Can I rollback multiple specific migrations together?
Yes, but not in a single –path value. Run the rollback multiple times with different –path values or use a custom script to loop over paths. Each invocation targets one path at a time.
Q3: How do I find the migration’s batch and status?
Check the migrations table in the database to see each migration’s name, batch number, and run status. This helps decide whether to use a batch rollback or a path-based rollback for precision.
Q4: What if migrate:rollback with –path does nothing?
Confirm the migration was previously run and exists in the migrations table, verify the relative path and filename, and ensure the down() method is implemented. If down() is empty or missing, Laravel can’t reverse the changes even if the command targets the file.
Q5: Is there a way to rollback “n” steps without specifying paths?
Yes. Use php artisan migrate:rollback –step=1 (or another number) to revert a given number of batches. This is different from path-based rollbacks and affects the most recent batches globally.
Q6: Can production databases safely use –path rollbacks?
They can, but follow best practices: back up the database, ensure the down() method accurately reverses schema changes, and test the rollback in a staging environment before running in production to avoid data loss or schema drift.
Q7: How do I re-run only one migration without touching others?
If the migration was already run, first rollback that file with –path, then run php artisan migrate –path=database/migrations/2025_08_10_123456_update_users_table.php to reapply just that migration.
Q8: Do I need the exact relative path for –path?
Yes. Provide the path relative to the project base (not an absolute path). Avoid spaces around the equals sign (use –path=… not –path = …), and ensure the filename matches the timestamped migration name exactly to prevent command errors.
Q9: What if I also need to reseed data after rolling back?
Append –seed to migrate:refresh to rollback, re-run the specified migration, and run database seeders: php artisan migrate:refresh –path=database/migrations/2025_08_10_123456_update_users_table.php –seed. This helps keep fixtures and test data in sync during development.