Confirm the production database identity, a restorable backup and the migration history in staging. Review locks, expected duration and the effect on code that may still be serving requests.

1. Read the pending migrations, including data updates and destructive changes. Rehearse them against a protected copy that represents the production schema and data volume.

2. Choose the deployment order. Adding a compatible column before new code uses it is often easier to reverse than immediately renaming or dropping a column used by the old release.

3. Record the current migration status and confirm the command will connect to the intended database. Run the approved production migration command once, using Laravel production confirmation handling only after these checks.

4. Watch the command result and database health. Prevent simultaneous deployment jobs from trying to apply the same release at the same time.

5. Verify the new schema and run representative read and write operations. Retain the migration output and backup reference with the release record.

From the intended release directory, as its application account with the correct PHP executable, first record:

php artisan migrate:status

Compare the pending list with the reviewed release and verify the database identity and restorable backup. After the agreed production checks and maintenance decision, the noninteractive execution command is:

php artisan migrate --force

--force suppresses Laravel's production confirmation; it does not supply backups, prevent destructive statements or guarantee transactional rollback. Run it through one coordinated deployment process and stop to inspect any failure rather than automatically repeating it.

Run php artisan migrate:status again, retain the output, and test old and newly created application records. Do not substitute migrate:fresh or migrate:refresh for a production deployment because they can drop or rebuild existing structures.

Check both application behavior and migration status. Test a newly created record, a previously existing record and any background job that accesses the changed tables.

After a failure, determine which migrations committed before retrying. Database engines and migration operations differ in transactional behavior. Do not assume a failed command automatically restored every earlier change.

• Planning a Laravel release rollback
• Deploying Laravel with a private application root
• Planning a backward-compatible database deployment
• Checking Laravel health without exposing private data

• Laravel migrations
• Laravel database access