Upgrading an old Laravel app: versions, PHP and how long it really takes
A planning guide for upgrading Laravel 7, 8, 9 or 10 to Laravel 13: which PHP each version needs, what slows an upgrade down, how we run one, and a recent 3-day example.
Hussain C · 4 min read
If your Laravel app is on version 11 or older, it's no longer getting security fixes. The good news: upgrading usually takes days or weeks, and it rarely needs a rewrite.
We recently took a SaaS app from Laravel 7 on PHP 7.2 to Laravel 13 on PHP 8.5 in 3 days, with no downtime. Here's how to plan yours.
Where does your version stand?
| Version | Minimum PHP | Security fixes |
|---|---|---|
| Laravel 7 | 7.2.5 | Ended March 2021 |
| Laravel 8 | 7.3 | Ended January 2023 |
| Laravel 9 | 8.0 | Ended February 2024 |
| Laravel 10 | 8.1 | Ended February 2025 |
| Laravel 11 | 8.2 | Ended March 2026 |
| Laravel 12 | 8.2 | Until February 2027 |
| Laravel 13 | 8.3 | Until early 2028 |
PHP has its own clock. PHP 7.2 stopped getting fixes on 30 November 2020, and PHP 8.1 at the end of 2025. When an emergency fix like PHP2Shell lands in October 2026, apps on those versions simply have nothing to install.
Why go one version at a time?
Each Laravel release has its own upgrade guide, and each one asks for a slightly newer PHP. Jumping six versions at once means six sets of changes failing together, with no way of telling which caused what.
One step at a time keeps every change small. If the tests fail after moving to Laravel 10, the cause is in the Laravel 10 changes, and that's a short list to read.
What decides how long it takes?
Mostly three things, and none of them is the size of the app.
Abandoned packages. Composer packages that stopped being updated years ago won't support PHP 8 or a new Laravel. Each one needs a decision: swap it for a maintained package, or move the small part your app actually uses into your own code.
Tests. With tests around the important flows, every step is checked in minutes. Without them, every step needs someone clicking through the app by hand. Writing tests first is the best time you'll spend on the whole upgrade.
Old auth and front-end scaffolding. Login and registration screens from the Laravel 7 era came from packages that have since been replaced. They have to be brought up to date carefully, because auth is where a quiet mistake locks people out or lets the wrong person in.
PHP's own changes matter too. PHP 8 is stricter about types and turns many old warnings into errors, so code that used to get away with sloppy input now fails loudly. Those fixes are small, but there are usually a lot of them.
How we run an upgrade
- Review. Read the code, list every package and check which ones support the target versions.
- Tests first. Sign-in, sign-up, payments and the main screens get tests against the old version, and they have to pass before step one.
- One version per step. Laravel Shift, a service that makes the routine upgrade changes, opens them as a pull request. Claude Code, a coding agent, works through the rest against the official upgrade guide. An engineer reads every change before it's kept.
- Staging rehearsal. The upgraded app runs on a copy of the live setup and gets tested end to end.
- One switch. The live site moves over once, at a quiet time, with a way back.
The coding agent does a lot of the typing: renames, method changes, working through failing tests one by one. It never merges its own work and never touches the live server.
A recent example: Laravel 7 to 13 in 3 days
A client's SaaS app had been on Laravel 7 and PHP 7.2 for years, with almost no tests. The plan above took it to Laravel 13 on PHP 8.5.
| Stage | Detail |
|---|---|
| Start | Laravel 7, PHP 7.2, almost no tests |
| Finish | Laravel 13, PHP 8.5, tests around the main flows |
| Time | 3 days: 2 of changes, 1 of testing |
| Hard parts | Abandoned packages, the old auth scaffolding, PHP 8 strictness |
| Go-live | Staging first, then one switch, no downtime |
The framework itself was the easy part. Laravel's upgrade guides are thorough. The time went where it usually goes: packages and tests.
Is your app due?
- On Laravel 11 or older? It's out of security support. Plan the upgrade now.
- On PHP 8.1 or older? It gets no more fixes either. Move it up with Laravel.
- No tests around sign-in and payments? Write those first, whatever else you do.
- Packages with no release in two years? Check each for PHP 8 support before you start.
Laravel apps are something we've built and looked after since its early versions, including the document e-signature platform we built on it. If yours is a few versions behind, our app rescue and modernisation work starts with a one-week review and a fixed quote. Or send us your Laravel and PHP versions and we'll tell you what the path looks like.
Frequently asked questions
Which Laravel versions still get security fixes?
As of late 2026, Laravel 12 gets security fixes until February 2027 and Laravel 13 until early 2028. Laravel 11 and everything older are out of security support, so apps on them get no fixes for newly found flaws.
Can you upgrade Laravel 7 directly to Laravel 13?
It's safer to go one major version at a time: 7 to 8, 8 to 9, and so on up to 13. Each version has its own upgrade guide and minimum PHP version, and small steps make it obvious which change broke what.
How long does a Laravel upgrade take?
It depends mostly on packages and tests. We recently upgraded a SaaS app from Laravel 7 on PHP 7.2 to Laravel 13 on PHP 8.5 in 3 days: 2 days of changes and 1 day of testing, with no downtime. Apps with many abandoned packages or no tests take longer.
What PHP version does Laravel 13 need?
PHP 8.3 or newer. Laravel 13 supports PHP 8.3, 8.4 and 8.5. Older apps usually move PHP up alongside Laravel, one step at a time.