- Laravel versions get 2 years of security fixes; Laravel 11 stopped receiving them on 12 March 2026.
- Upgrade one major version at a time, following the official upgrade guide for each step.
- Add tests for your most important flows before you start, so you can prove nothing broke.
- Check PHP support too: PHP 8.2 security support ends on 31 December 2026.
How do you safely upgrade an old Laravel application?
Audit your Laravel, PHP and package versions, add tests around your most important flows, then upgrade one major version at a time using the official upgrade guide for each step, updating packages and PHP along the way, and deploy through a staging copy first. Old versions stop getting security fixes, so an outdated app is a growing risk even when it still works. A planned, step-by-step upgrade is far safer and cheaper than a rushed one after a security problem.
This is the process our Laravel development team follows. If you are still choosing a stack for a new product, read Laravel or Node.js for your back end first.
Why upgrade if the app still works?
According to Laravel's support policy, every release gets bug fixes for 18 months and security fixes for 2 years. Laravel 10 stopped receiving security fixes on 4 February 2025 and Laravel 11 on 12 March 2026. Laravel 12 gets security fixes until 24 February 2027, and Laravel 13, released in March 2026, is the current version. Running an unsupported version means new vulnerabilities will not be patched, and newer packages and PHP versions stop working with it.
Why does the PHP version matter too?
Each Laravel version supports a range of PHP versions, and PHP itself has end dates. PHP's supported versions page shows PHP 8.2 security support ending on 31 December 2026 and PHP 8.3 on 31 December 2027. Laravel 13 needs PHP 8.3 or newer. So most upgrades include a PHP upgrade on the server as well, which your host or DevOps team needs to plan.
Which signs show an app needs upgrading now?
- The Laravel version is out of security support, or will be within six months.
- The server runs a PHP version that no longer receives security fixes.
- New packages you want to use will not install because of version conflicts.
- Your host is retiring the PHP version you depend on.
- Developers avoid touching parts of the code because changes keep breaking things.
Step 1: What should the audit cover?
- Current Laravel and PHP versions, in production and in development.
- Every Composer and npm package, its version, and whether it supports the target Laravel version.
- Abandoned packages that need a replacement.
- Custom code that overrides framework behaviour.
- Existing tests and how much of the app they cover.
- Server setup: queues, scheduled tasks, caches and storage.
Step 2: Why add tests before changing anything?
Tests are how you prove the upgrade did not break anything. If coverage is low, write feature tests for the flows that matter most: sign-in, checkout or payments, key forms, reports and any integrations. Even a modest set of tests on critical paths turns the upgrade from guesswork into a checklist.
Step 3: How do you move through the versions?
- Create a branch and a staging environment that mirrors production.
- Upgrade one major version at a time, following the official upgrade guide for that version.
- Update packages to versions that support the new release, replacing abandoned ones.
- Run the tests, fix failures, and click through the app by hand.
- Commit and repeat for the next version.
Tools such as Laravel Shift, a paid service that automates many upgrade changes, and Rector, which rewrites PHP code automatically, can speed up the mechanical work. Review their changes like any other code.
What about the front end?
Older Laravel apps often use Laravel Mix for front-end assets, while newer versions use Vite. Moving to Vite is usually part of a full upgrade and needs its own testing, especially for JavaScript-heavy pages. Plan it as a separate step so problems are easier to trace.
Step 4: How do you deploy without downtime?
- Back up the database and files.
- Upgrade PHP on staging first, then deploy the upgraded app there and test with a copy of real data.
- Schedule production deployment for a quiet period, with a tested rollback plan.
- After launch, watch error logs, queues and scheduled tasks closely for a few days.
What should you ask your developer or agency?
- Which Laravel and PHP versions are we on, and when does support end?
- Which packages block the upgrade, and what are the replacements?
- Which flows will be covered by tests before the upgrade starts?
- How will staging mirror production, and what is the rollback plan?
- What will it cost to keep the app current each year after this?
How do you avoid falling behind again?
Plan a yearly upgrade when each new major version comes out, keep packages updated monthly, and keep the tests growing. Laravel says it aims to make each major upgrade possible in a day or less, which is realistic when you stay current. Ongoing maintenance and security care keeps the app on supported versions so you never face a multi-version jump again.
Frequently asked questions
How long does a Laravel upgrade take?
It depends on how many versions you are behind, how many packages you use and how much test coverage exists. A single version step on a well-tested app can be quick, while jumping several versions on an untested app with abandoned packages can take weeks. An audit of versions and packages gives a realistic estimate.
Can we skip versions and jump straight to the latest?
It is safer to step through each major version, following each official upgrade guide, because every guide lists the changes from the version before. You can move through the steps quickly, but doing them in order makes problems much easier to find and fix.
What if a package we rely on is abandoned?
Look for a maintained fork or an alternative package, or replace the feature with Laravel's own functionality where it now exists. Sometimes the right answer is a small rewrite of that part of the app. Find these packages early in the audit, because they often decide the timeline.
Is it better to rebuild instead of upgrading?
Rarely. Upgrading keeps your working business logic and data, and costs less. A rebuild only makes sense when the app's design no longer fits the business, the code is so tangled that changes are unsafe, or you are changing the product substantially anyway.
Last updated