A Laravel upgrade should leave the business with a supported application and confidence that its important workflows still work. Changing the framework version is one step in that process. The larger job is understanding the application, its dependencies and the production environment.
This checklist is for planning an upgrade assessment. It is not a command sequence for every Laravel version: breaking changes, PHP requirements and package compatibility depend on the installed version and the chosen target.
Record the application you actually have
Confirm the deployed Laravel and PHP versions, database engine, Composer lockfile, front-end build tools, queue driver, scheduled jobs and hosting setup. Compare production with the repository and staging environment. An upgrade plan based on an outdated development copy can miss the behavior users rely on.
- List first-party and third-party packages and the features that depend on them.
- Identify custom service providers, authentication changes and framework extensions.
- Document external APIs, webhooks, background workers and file storage.
- Check who can deploy, access backups and operate the application after release.
Choose a supported target and a deliberate path
Use the official release information and upgrade guide for the target major version. Check its PHP requirement against the actual host and every deployment environment. Review intermediate major-version changes if the application is several releases behind.
Do not copy an upgrade command from an unrelated application and assume it fits. A package may block the target version, require its own migration or have no maintained replacement. Resolve those decisions before scheduling a production change.
Keep the lockfile in the reviewed release so the packages tested in staging are the packages deployed. Treat major dependency changes as application changes that need review, rather than an incidental part of deployment.
Build a compatibility and risk register
| Area | Questions to resolve |
|---|---|
| Runtime and packages | Does the target support the host PHP version? Which packages need replacement or migration? |
| Authentication and permissions | Do login, sessions, password recovery and role boundaries behave correctly? |
| Data and integrations | Are database changes compatible? Can webhooks and API requests be safely retried? |
| Background work | Will queued jobs and scheduled tasks use the correct release and configuration? |
| Operations | Are backup restoration, deployment checks and recovery responsibilities clear? |
Test business behavior before and after the upgrade
Start with the workflows that would hurt the business if they broke: a booking, an invoice, a staff approval or a customer login. Capture the current expected behavior first. Otherwise, a pre-existing defect can be confused with an upgrade regression.
Use automated tests where they provide meaningful coverage, and a short manual acceptance checklist for important interfaces. Include permissions and failure paths, rather than testing only a successful administrator journey. Run integrations against suitable test environments or controlled substitutes so an assessment does not create real payments or send customer notifications.
If the application has little test coverage, add a focused safety net around the riskiest workflows before making broad changes. A passing framework test does not prove a custom approval process still respects its roles.
Rehearse migrations and recovery
Take backups appropriate to the database and uploaded files, and verify that a restoration procedure works. Keep access credentials and a recovery copy outside the application’s public directory. A backup file that nobody has tried to restore leaves an important uncertainty unresolved.
Rehearse database migrations on a safe, appropriately protected copy. Consider lock time, data volume and whether old and new application releases can operate against the changed schema. Rolling back application files may be insufficient after an incompatible schema change. Some incidents require a forward fix or a deliberate data recovery process.
Deploy the whole application, including workers
The web process is only part of many Laravel systems. Coordinate configuration caching, compiled views, queue-worker restarts and scheduled tasks using the target version’s deployment guidance. Confirm that the production debug setting is off and that writable directories and storage links have the correct permissions.
- Agree a change window and the person responsible for the go/no-go decision.
- Deploy the reviewed release and run its planned database changes.
- Check health, critical workflows, queue processing and application logs.
- Monitor failed jobs, integration errors and response times after release.
- Use the rehearsed recovery plan if the agreed acceptance checks fail.
Separate the upgrade from a larger redesign
An upgrade may expose opportunities to improve performance or simplify architecture. Record them, then decide which are essential for compatibility and which should be delivered separately. Keeping the release focused makes changes easier to review and problems easier to isolate.
For a useful assessment, bring repository access, environment details, the current pain points and a list of critical workflows. Explore Delphro’s software maintenance and modernization services or cloud and deployment support.
Official references
Check the Laravel release and support information, the Laravel 13 upgrade guide when that is your target, and the matching version’s deployment documentation. Requirements can change; use the guide for the version you are actually deploying.
