Laravel migrate:rollback Migration File Immutability Constraint

Migration Rollback Safety

Laravel's migrate:rollback command reverses the most recent migration batch by executing each down() method against the current database schema. The framework does not enforce migration file immutability or inspect schema drift before running down(), so editing an executed migration can cause the rollback to operate on a schema that no longer matches the migration's original assumptions.

This leaves an unresolved design decision about whether rollback should be blocked when a previously executed migration file has changed, or when manual schema changes have altered tables targeted by down(). Without a native guard, teams must rely on discipline rather than an enforced constraint.

• Should migrate:rollback verify that executed migration files are unchanged before executing down()?
• Is there a configuration option to abort rollback when schema drift is detected for migrations in the current batch?