The support window is the measure
Laravel ships major versions to a fixed rhythm. For each one it is documented how long it receives bug fixes and how much longer after that it receives security fixes. While a version sits inside its security window, an older number is not a problem. It is a decision.
It gets interesting at the end of that window. From then on, reported vulnerabilities in your version are no longer closed. They stay public all the same; the advisory does not disappear. This is where a task you could plan turns into one that presses.
The same applies one level down for PHP. In practice the PHP version is the trigger more often, because hosts switch old versions off and you then get a deadline you did not set.
Where the versions currently stand
Laravel ships a new major version once a year, usually in the first quarter. Each one gets eighteen months of bug fixes and two years of security fixes. The release notes no longer list an LTS version in the earlier sense; the same window applies to every major release.
| Version | Released | Bug fixes until | Security until |
|---|---|---|---|
| Laravel 10 | 14 Feb 2023 | 6 Aug 2024 | 4 Feb 2025 |
| Laravel 11 | 12 Mar 2024 | 3 Sep 2025 | 12 Mar 2026 |
| Laravel 12 | 24 Feb 2025 | 13 Aug 2026 | 24 Feb 2027 |
| Laravel 13 | 17 Mar 2026 | Q3 2027 | 17 Mar 2028 |
From that you can read your own position in one sentence. Anyone on Laravel 11 or older gets no security fixes at all; for version 11 the window closed in March 2026. Laravel 12 has been security-only since August 2026 and receives no more bug fixes. The current release is Laravel 13.
The table is here for looking up and is no substitute for the official release notes. These figures were checked on 28 August 2026.
The three signals that matter
One: is the security window running out? If it is, the upgrade belongs in this year’s planning, not in a list of ideas.
Two: can dependencies still be updated? A package demanding a newer PHP version blocks
every other one. When composer update starts contradicting itself in several places at once,
the arrears are already large.
Three: does anyone still dare to deploy? That is not a technical signal, but it is a reliable one. When nobody on the team changes anything voluntarily any more, the substance is the problem, not the version number.
Why small steps come cheaper
An upgrade across one major version is usually manageable. A few renamed methods, a changed default, an adjusted configuration. Across four major versions it becomes a project, because the changes pile on top of each other and at some point nobody knows which adjustment caused which fault.
So the cheapest strategy is not to fall behind in the first place. A fixed date once a year on which the application is brought up to the current release costs reliably little. The catching-up date after five years costs unreliably a lot.
How a jump like that runs
We work in a copy and lift it there stage by stage. After every stage the test suite runs. Where there is none, we build one first for the places where a mistake really hurts. Only once every stage is through does the finished state go live in a short window. By then the way back has been rehearsed, in case we have missed something.
How we go about it in detail is under migration and upgrades. If the first question is what state the application is in at all, a code audit is the right place to start.
