Keep a known-good release, the deployment record and a tested database backup. Identify which migrations and background jobs the new release introduced before choosing a recovery method.

1. Pause further deployments and decide whether the site needs maintenance mode or a brief write restriction. Protect new customer data while you assess the fault.

2. Compare the old code requirements with the current database schema. Use a code rollback only when the old release remains compatible, or prepare a coordinated repair.

3. Switch the active application path through the supported deployment mechanism. Reuse the correct production secrets and persistent upload directories.

4. Rebuild release-specific caches and restart the relevant workers so old and new code do not continue running together unintentionally.

5. Check failed or in-flight jobs before retrying them. An email, payment request or other external action may already have happened even when the application reported an error.

Verify important customer workflows, current records and recently uploaded files. Confirm the release identifier, worker code and application log all correspond to the selected recovery state.

If the old release cannot use the new schema, a targeted forward fix may preserve more recent data than restoring an old database. Test the chosen approach before a destructive restore.

• Running Laravel database migrations in production
• Publishing Laravel public storage safely
• Rolling back application files without losing new user data
• Checking Laravel health without exposing private data

• Laravel migrations
• Laravel queues