Running an older Laravel app? PHP support, Laravel end of life and your upgrade path

Quick answer: In a Laravel application, the framework version and the PHP version are linked — each Laravel release only supports a specific range of PHP. So when PHP 8.2 reaches end of life on 31 December 2026, an older Laravel app (Laravel 9, for example, which tops out at PHP 8.2) can no longer run on a PHP version that’s still supported without a framework upgrade too. If you run a custom Laravel app, the job is to check both versions, work out your real deadline, and choose between an in-place upgrade, a staged upgrade, or a more substantial rebuild.

Most of our PHP writing is aimed at WordPress and WooCommerce owners, because that’s most of the web. But a lot of Australian businesses run something more bespoke — a custom portal, an internal tool, a SaaS product — built on Laravel, PHP’s most popular application framework. Those apps have an extra wrinkle worth understanding, because it changes your timeline.

Why Laravel and PHP are a package deal

With WordPress, you can often bump the PHP version while keeping roughly the same site. With a framework like Laravel it’s tighter: each Laravel version officially supports only a certain band of PHP versions. Run PHP outside that band and you’re in unsupported, often broken, territory.

That coupling matters right now because of PHP’s own end-of-life schedule. If your Laravel version only supports PHP up to a release that’s about to lose security support, your framework version has effectively set a deadline for you.

The Laravel support picture

From Laravel’s own release documentation, Laravel provides bug fixes for 18 months and security fixes for 2 years after a release. Mapping the recent versions to their PHP bands and security end dates:

Laravel	Supported PHP	Security fixes until
9	8.0 – 8.2	Ended 6 Feb 2024
10	8.1 – 8.3	Ended 4 Feb 2025
11	8.2 – 8.4	Ended 12 Mar 2026
12	8.2 – 8.5	24 Feb 2027
13	8.3 – 8.5	17 Mar 2028

Two things jump out. First, Laravel 9, 10 and 11 are all already past their own security-fix dates — so an app on any of them is running an unsupported framework today, regardless of PHP. Second, here’s the deduction worth drawing (and we’re labelling it as a deduction from the table above, not an official Laravel statement):

A Laravel 9 app can only run on PHP up to 8.2. Once PHP 8.2 reaches end of life on 31 December 2026, that app can no longer run on any PHP version PHP itself still supports — unless the framework is upgraded first.

So for the oldest Laravel apps, the PHP deadline and a framework upgrade arrive at the same moment. That’s not cause for panic, but it is cause to start planning well before December.

Your three realistic options

How you move depends on how far behind you are and how the app is built.

1. In-place upgrade (one or two versions)

If you’re only a version or two behind — say Laravel 11 heading to 12 — an in-place upgrade following Laravel’s upgrade guide is often the right call. It’s the least disruptive path: same app, newer framework and PHP, tested and shipped.

2. Staged upgrade (several versions behind)

If you’re several major versions back (Laravel 9, for instance), you usually can’t leap straight to the latest. A staged upgrade — moving up one major version at a time, testing at each step — is slower but far safer, because each hop has a documented upgrade guide and a smaller set of breaking changes to absorb.

3. Rebuild the core

Sometimes an app is old enough, or was built loosely enough, that upgrading through several versions costs more than it’s worth — and you’d be carrying forward design decisions you’d no longer make. That’s a genuine judgement call, and we’ve written a whole framework for making it honestly in when to rewrite versus refactor legacy software. The short version: rewrite when the old code actively blocks what the business needs next, not just because it’s old.

Whichever path, test before you commit

Custom apps earn their keep in the details — the background jobs, the integrations, the edge cases real users hit. Before any upgrade goes live, it needs a proper test pass on a staging environment: run the test suite if one exists, exercise the critical workflows by hand, and check every integration. An upgrade that “looks fine” on the home page can still have broken a nightly job or a third-party sync.

Getting help with it

Upgrading or rebuilding a Laravel app is real engineering work, and it’s the kind of thing we do — see our custom web app development and SaaS development work. If you’ve got a Laravel app and you’re not sure where it stands against these deadlines, start a project and we’ll assess the framework version, the PHP band, and the most sensible path — upgrade or rebuild — before you commit to either.

Common questions

Is upgrading PHP enough for my Laravel app? Often not. Because Laravel supports only a specific range of PHP versions, moving to a newer PHP may require moving to a newer Laravel version too. Check both, not just PHP.

My Laravel app is on version 9 (or 10, or 11). Is that a problem? Those versions are already past Laravel’s own security-fix dates, so the framework itself is unsupported regardless of PHP. It’s worth planning an upgrade path — and if you’re on Laravel 9, note that it can’t run on a supported PHP version once PHP 8.2 ends on 31 December 2026.

Should I upgrade Laravel in place or rebuild the app? If you’re only a version or two behind, an in-place or staged upgrade is usually best. A rebuild makes sense when the old codebase actively blocks what the business needs next, not simply because it’s old — it’s a deliberate decision worth weighing carefully.

How long does a Laravel upgrade take? It depends entirely on how many major versions you’re crossing, how much custom code and how many integrations the app has, and whether it has automated tests. A one-version bump can be quick; a jump from Laravel 9 to the latest is a staged project. An assessment first tells you which you’re facing.