What must pass before a Laravel upgrade goes live?
A practical acceptance checklist for permissions, data changes, queues, scheduled work and recovery after a Laravel upgrade.
Faith Forge Labs ยท Reviewed October 16, 2026
A successful dependency update is one checkpoint. Before an upgrade goes live, the people responsible for the application need to know which everyday tasks still work, how failures appear, and how to recover.
What belongs in the upgrade scope?
Record the current and target Laravel and PHP versions, the lockfile revision, required extensions, database engine, queue driver and scheduler. Include the web runtime and background workers. Resolve package blockers before scheduling the release; the compatibility guide explains the difference between a supported version pair and an application that is ready.
Which checks should the business be able to repeat?
| Journey | Check | Keep as evidence |
|---|---|---|
| Sign-in and permissions | A permitted role can complete its task; a restricted role cannot access it. | Synthetic accounts, expected permissions and the test result. |
| Database changes | Migrations work against the production database dialect on an isolated copy containing synthetic data. | Migration order, restore rehearsal and any irreversible step. |
| Queued work | A task completes once; retrying a failure does not duplicate the business action. | Job identifier, retry behaviour and resulting synthetic record count. |
| Scheduled work | The task runs at the intended time and handles overlapping runs as designed. | Timezone, schedule and result. |
| External integration | Success, rejection and timeout paths produce understandable states. | Sandbox or stub responses, without live messages or charges. |
What would make us stop the release?
Agree on concrete stop conditions: a permission check fails, a migration has no rehearsed recovery path, a worker uses the wrong PHP version, or a critical journey is still untested. Assign the decision to a role before release day. A green unit-test suite does not answer every one of these questions.
How does rollback work after data changes?
Restoring yesterday's database may discard today's work. Write down whether old code can run against the new schema, when writes would need to pause, and how new records would be reconciled after recovery. Prefer a reversible sequence where the application's needs allow it. Rehearse restoration away from production and record the time it takes.
Fictional demonstration: a queued report after an upgrade
This invented example uses no customer data. A synthetic user requests report DEMO-REPORT-7. The request creates one job, the worker produces one report, and the user can open it. A second run makes the worker unavailable; the interface shows the pending state. Restarting the worker completes that same job without adding another report. Repeat the permission check with a synthetic user who should not see it.
What should remain after handoff?
Keep the released revision, tested versions, acceptance results, deployment steps and recovery limits together. Name the role that checks failures after launch and the role that can approve a rollback. Use the upgrade planner for a first outline, then discuss the application and its release constraints with Faith Forge Labs. The planner cannot inspect your code or certify its security.