Laravel migrate:rollback Migration File Immutability Constraint

Direct Answer

No, Laravel's migrate:rollback does not verify that executed migration files are unchanged before running their down() methods. There is also no configuration option in config/database.php or elsewhere to abort rollback when schema drift is detected for migrations in the current batch.

Confirmed Behavior (Laravel 8.x–11.x)

• The migrations table stores only the migration filename (migration column) and batch number (batch column). No file hash, checksum, or schema snapshot is recorded.
• Illuminate\Database\Migrations\Migrator::rollback() retrieves migrations by batch number and executes each down() method without comparing the current file contents to what was originally run.
• If you edit a migration after it has been executed, migrate:rollback will run the current down() code against the current database schema. This can cause errors or silent data corruption if the edited down() no longer matches the schema created by the original up().
• Manual schema changes (raw SQL, external tools, direct DDL) are similarly invisible to the rollback process.

Why This Matters

Rollback is designed for reversing the most recent batch during development or failed deployments. It assumes an append-only migration history. Once a migration is executed and committed, the framework treats its file as immutable by convention, not by enforcement.

Practical Mitigations Teams Use

1. Treat migrations as append-only. Never edit an executed migration. Write a new migration for any schema change.
2. CI guard. Add a pipeline step that fails if any file listed in the migrations table has a git diff against the commit where it was first applied (or simply forbid changes to files under database/migrations/ after merge).
3. Third-party package. spatie/laravel-migration-guard (or similar) can compute and store file hashes, then abort rollback if a hash mismatch is detected. This is opt-in, not built-in.
4. Prefer migrate:fresh in CI/CD. Rebuilding from scratch avoids rollback entirely for test environments.

Verification You Can Run Locally

# 1. Create and run a migration
php artisan make:migration create_posts_table
php artisan migrate

# 2. Edit the migration file (e.g., change down() to drop a different table)
# 3. Rollback the last batch
php artisan migrate:rollback --step=1
# Observe: the edited down() executes without warning

# 4. Inspect the migrations table
php artisan tinker --execute="DB::table('migrations')->get()"
# Only migration name and batch are stored

One Diagnostic Detail

Are you encountering a specific rollback failure after a migration file was edited, or are you designing a policy/guard for your team? The answer changes whether you need a quick fix (write a compensating migration) or a process change (CI hash check).