Laravel 13 vs 12 vs 11: Should Your Perth Business Upgrade?

If your business runs a Laravel application, the upgrade question changed in 2026.

Laravel 13 was released in March 2026. Laravel 11 has now passed its security support window. Laravel 10 has been unsupported for more than a year. Laravel 12 is still supported and remains a sensible place to be, but it is no longer the newest major version.

That does not mean every business should rush to Laravel 13 this week. It does mean the old "we will look at it later" answer is no longer good enough if your application is on Laravel 11 or older.

We have been building Laravel applications in Perth since 2013, from Laravel 4 through to the current generation. This is the practical upgrade advice we give Australian businesses: what is supported, what is risky, what the upgrade usually costs, and when waiting is actually the better decision.

The short answer

• Laravel 13 is the current major release. It is the right default for new builds if your hosting stack can run PHP 8.3 or newer.
• Laravel 12 is still actively supported. If you are already on Laravel 12 and the application is stable, you can plan an upgrade instead of treating it as an emergency.
• Laravel 11 reached the end of security support on 12 March 2026. If you are still on Laravel 11, you should have an upgrade plan now.
• Laravel 10 reached the end of security support on 4 February 2025. If you are still on Laravel 10, this is already a security and maintenance issue.
• Laravel 9 or earlier should be treated as legacy software. The question is not whether to upgrade; it is whether to upgrade in place or modernise in phases.

Laravel's official release notes list the support windows clearly: bug fixes for 18 months and security fixes for two years for each major release. As of June 2026, the key dates are Laravel 11 security support ended on 12 March 2026, Laravel 12 security support runs until 24 February 2027, and Laravel 13 security support runs until 17 March 2028. You can verify the current table in the Laravel release notes.

What changed between Laravel 11, 12, and 13

Laravel's recent releases have been more evolutionary than disruptive. That is good for businesses: the upgrade work is usually around PHP versions, third-party packages, deprecated code, tests, and deployment configuration rather than rewriting the whole application.

Laravel 11: the skeleton change

Laravel 11 introduced the biggest visible framework change in this group: a simplified application structure. New Laravel 11 apps moved middleware, exception handling, and routing configuration into bootstrap/app.php, and the default project skeleton became much leaner.

For existing applications, that change is not as frightening as it sounds. You do not have to remodel your whole codebase just to upgrade. The real Laravel 11 upgrade work usually comes from:

• PHP 8.2 compatibility
• outdated first-party and third-party packages
• old middleware or exception handling customisations
• test failures caused by dependency changes
• deployment scripts assuming older directory conventions

Laravel 11 was a strong release, but by June 2026 it is no longer supported. That matters more than the feature list.

Laravel 12: the stable business target

Laravel 12 was a refinement release. It continued the improvements from Laravel 11 without a major architectural shift.

For many businesses, Laravel 12 is the practical intermediate target. If your application is on Laravel 10 or 11, moving to Laravel 12 can be the right first step before considering Laravel 13, especially when:

• the application has older packages that are not Laravel 13 ready
• the hosting environment is not yet on PHP 8.3
• the business needs a lower-risk upgrade path
• the codebase has limited automated tests

Laravel 12 security support runs until 24 February 2027, so it buys real time. That does not mean you should stop there forever, but it can be a sensible staging point.

Laravel 13: the new default for new work

Laravel 13 is the current major release and the default choice for new Laravel builds in 2026. It requires PHP 8.3 or newer and continues the recent trend of smaller major-version jumps.

The headline changes include first-party AI tooling, JSON:API resources, request forgery protection improvements, queue routing by class, and expanded PHP attribute support. Those are useful, but the main business reason to choose Laravel 13 is simpler: it gives you the longest support window and keeps new development aligned with the current ecosystem.

For existing applications, Laravel 13 is usually worth targeting when:

• your infrastructure already supports PHP 8.3+
• your core packages support Laravel 13
• you are about to start a major feature phase
• the application is public-facing or compliance-sensitive
• you want to avoid doing another major upgrade in 6 to 12 months

Which version should your business be on?

Here is the practical decision tree.

If your Laravel app is internal, stable, and behind a private network, the urgency may be lower. If it is public-facing, handles personal information, takes payments, supports operations, or is used by government or regulated clients, unsupported Laravel versions are not a small housekeeping issue. They are a business risk.

What an upgrade actually involves

A proper Laravel upgrade is not just changing laravel/framework in composer.json.

For a normal business application, the process looks like this:

1. Audit the current stack. Check Laravel, PHP, database, queue workers, cache, deployment scripts, packages, and abandoned dependencies.
2. Map the upgrade path. Decide whether to go directly to Laravel 13 or stage through Laravel 12.
3. Upgrade PHP and packages. This is often where the real work sits.
4. Fix framework-level changes. Middleware, config, exception handling, service providers, factories, policies, queues, and scheduler behaviour all need checking.
5. Run and repair tests. If the app has weak tests, budget extra time for manual regression testing.
6. Deploy safely. Use staging, backups, rollback steps, queue worker restarts, cache clearing, and post-deploy smoke tests.

The applications that upgrade cheaply have boring dependency graphs, current PHP versions, and tests that tell the truth. The expensive ones have abandoned packages, hidden production-only behaviours, no tests, and deployment scripts nobody has touched in years.

Typical cost in Perth

For a mid-sized Laravel application with 50 to 200 routes, 30 to 80 models, and 10 to 20 third-party packages, these are realistic Perth price bands:

Those ranges assume the application is maintainable. A smaller app can be cheaper. A larger app with no tests, old PHP, bespoke authentication, complex queues, or abandoned packages can cost more.

This is why we normally start with a fixed-scope codebase audit. For most Laravel applications, a one-week audit is enough to identify the real upgrade path, the risky packages, the PHP and infrastructure blockers, and a fixed-price quote for the upgrade itself.

When upgrading can wait

Upgrading can wait when you are already on Laravel 12, the app is stable, your dependencies are patched, and there is no major feature work planned this quarter.

It can also wait briefly if you are replacing the application. But be honest about the replacement timeline. "We are rebuilding it soon" is one of the most common reasons old software stays in production for another three years.

Waiting is not sensible when:

• the app is on Laravel 11 or older
• it is exposed to the public internet
• it stores personal, financial, health, government, or operational data
• your cyber insurance or client contracts require supported software
• package updates are blocked because the framework is too old
• developers are avoiding the codebase because the stack is stale

Unsupported software does not fail dramatically on the day support ends. It gets harder to patch, harder to host, harder to staff, and harder to trust.

Should you upgrade or rebuild?

Most Laravel applications should be upgraded, not rebuilt.

A rewrite sounds clean because it avoids touching old code. In practice, it often means re-discovering years of business rules by breaking them one at a time. If the application broadly works and the business still depends on it, upgrading in place is usually cheaper and safer.

A rebuild starts to make sense when:

• the application no longer reflects the business process
• the database model is fundamentally wrong
• the UI is unusable and every workflow needs redesign
• the codebase is full of abandoned custom framework code
• there are no tests and no one understands the production behaviour
• a major platform shift is needed anyway

Even then, the best path is often phased modernisation: stabilise the existing Laravel app, upgrade the runtime, then replace the worst parts incrementally.

The bottom line

If you are on Laravel 12, you are in a reasonable position. Plan Laravel 13, but do it on your terms.

If you are on Laravel 11, the support window has closed. Put an upgrade plan in motion.

If you are on Laravel 10 or older, the risk is no longer theoretical. The longer you wait, the more the upgrade becomes a modernisation project.

If you need help deciding where your application sits, talk to our Laravel team. We can review the codebase, identify the safest upgrade path, and tell you plainly whether Laravel 13 is worth doing now or whether Laravel 12 is the better first step.

Nano Solutions has been building Laravel applications in Perth since 2013. We are on the WA Government CUAICTS2021 panel (Contractor #225) and active members of the Australian Laravel community. Learn more about our Laravel development services or our Laravel modernisation service.