Laravel Upgrade Guide: Planning 9 to 13 Without Breaking Production

Most Laravel upgrades are less dramatic than the version numbers suggest. The framework’s own guides put a single major step at between 5 and 15 minutes. The real work sits around the framework: PHP, packages, Nova, tests and the hosting environment.

This is how we plan an upgrade for Australian businesses running Laravel 9 to 12. We cover what breaks at each step, what to check first, how long it really takes and when to stop upgrading and rebuild. Dates were checked against laravel.com and php.net in November 2026.

Laravel support dates, 9 to 13

Laravel gives each release 18 months of bug fixes and two years of security fixes. Here is where each version stands today.

Laravel	PHP	Released	Bug fixes until	Security fixes until
9	8.0 to 8.2	8 February 2022	8 August 2023	6 February 2024
10	8.1 to 8.3	14 February 2023	6 August 2024	4 February 2025
11	8.2 to 8.4	12 March 2024	3 September 2025	12 March 2026
12	8.2 to 8.5	24 February 2025	13 August 2026	24 February 2027
13	8.3 to 8.5	17 March 2026	Q3 2027	17 March 2028

Laravel 9, 10 and 11 are past security support. Laravel 12 receives security fixes only until 24 February 2027. Only Laravel 13 still gets bug fixes.

PHP has its own clock. PHP 8.0 and 8.1 are end of life, and PHP 8.2 stops receiving security fixes on 31 December 2026. We cover those dates in PHP 8.2 end of life, so we do not repeat them here. The practical point: an old Laravel version is usually also an old PHP version, and the two deadlines should be planned as one piece of work.

What actually breaks, version by version

The upgrade guides list every breaking change, most of them in corners of the framework a typical application never touches. These are the ones that tend to matter.

Laravel 9 to 10

The guide estimates 10 minutes. PHP 8.1 and Composer 2.2 become the minimum.

• Dependency versions. Sanctum, Passport, Laravel UI and Ignition all need new major versions. PHPUnit 10 is optional.
• Monolog 3. Any code that touches Monolog directly, and third-party log handlers such as Bugsnag or Rollbar, may need new package versions.
• The $dates property on Eloquent models is removed. Move those columns to $casts.
• Removed test traits. MocksApplicationServices is gone, so tests using expectsEvents or expectsJobs move to Event::fake and Bus::fake.

Laravel 10 to 11

The guide estimates 15 minutes. It also lists more high-impact items than any other recent step.

• PHP 8.2 and curl 7.34 are required.
• Migrations that change columns. A change() call now drops any modifier you do not repeat, such as unsigned, default or comment. Squashing migrations avoids rewriting old ones.
• Floating-point columns. double and float are rewritten to be consistent across databases, and the unsigned decimal helpers are removed.
• First-party packages. Sanctum, Passport, Cashier, Telescope and Spark each move to a new major version, and they stop loading their own migrations, so you publish them into the application.
• Carbon 3 is optional, but diffIn* methods return floats and can be negative, so date logic needs a look.
• SQLite 3.26 or later is required.

The new slimmer application structure is not required. Laravel’s own guide recommends against migrating older applications to it.

Laravel 11 to 12

The guide estimates 5 minutes, and the high-impact list is only the dependency bump to ^12.0 (with PHPUnit 11 and Pest 3) and the Laravel installer update.

• Carbon 3 is now mandatory. Carbon 2 is no longer supported.
• HasUuids produces UUIDv7. Existing code that expects v4 switches to HasVersion4Uuids.
• The image validation rule excludes SVG unless you allow it.
• The default local disk root moves to storage/app/private if you did not define the disk yourself, which can quietly change where uploads land.

Laravel 12 to 13

The guide estimates 10 minutes. Laravel says it kept breaking changes to a minimum. PHP 8.3 is the floor.

• Dependencies: Tinker 3, PHPUnit 12 and Pest 4.
• CSRF middleware is renamed PreventRequestForgery and now checks request origin. The old names remain as deprecated aliases.
• Cache serializable_classes defaults to false in the new skeleton config. An application that caches PHP objects must list the classes allowed back out of the cache.
• Session serialisation defaults to json in the skeleton. Syncing that config over an existing app logs every user out.
• Cache key prefixes and session cookie names change if you relied on framework defaults.

The Laravel guides call these estimates a guide, not a quote. They assume your code uses little beyond the framework.

One major at a time, or a jump

We take one major at a time, with a release between each. Each guide describes a single transition, so a failing test points to a small set of changes. The risk of a jump is not the volume of changes. It is that failures from three versions arrive at once, with nothing to separate them.

A jump is reasonable for a small application with good tests and few packages. Even then, we run the intermediate versions in a branch and read each guide.

Plan the upgrade before touching code

1. Inventory the runtime

Record the PHP version, extensions, queue workers, scheduled jobs and the hosting setup. Cron and queue workers do not always use the same PHP binary as the website.

2. Audit dependencies

Composer shows what blocks you:

composer outdated --direct
composer why-not laravel/framework 13.0

Each blocker is a package to upgrade, replace or remove. Abandoned packages are the usual cause of a stalled upgrade, so decide early which ones go.

3. Nova and first-party packages

Nova has its own version line. Nova 5 lists Laravel 10.x to 13.x and Inertia 2, and its installation example uses PHP ^8.2. Its upgrade guide moves custom fields and tools to @inertiajs/vue3, so any custom Vue component needs work. Upgrade Nova on a Laravel version it supports before moving Laravel again. Our statements of work pair Nova upgrades with framework upgrades.

Check Sanctum, Passport, Cashier, Horizon and Telescope against each target version. As the 10 to 11 guide shows, they can add steps of their own.

4. Tests first

An upgrade without tests relies on someone clicking through the application. If coverage is thin, we write characterisation tests around the paths that would hurt most: payments, logins, imports, queued jobs and emails. Run the suite on the current version first so you know it is green before anything changes. Our legacy PHP inheritance guide covers how to judge test coverage honestly.

5. Use the tooling

Laravel Shift is a community-maintained service that automates framework upgrades, and Laravel’s own guides point to it. Laravel 13 adds an AI-assisted route through Laravel Boost. Rector handles PHP-level rewrites such as deprecations. These tools do the mechanical part. They do not decide which packages to keep or prove the application still behaves the same, so we treat their output as a draft pull request that gets reviewed and tested.

6. Staging and rollback

Run each step on a staging copy of production data and the same PHP build. Deploy at a quiet time with the previous release ready to redeploy, and take a database backup first. Watch the logs after release, because some paths only run under real traffic. Migrations that alter data are the step that is hardest to reverse, so we make those separate, reviewed releases.

How long it takes in practice

The framework change is the small part. Time goes on:

• packages that have no release for the new version;
• a thin or missing test suite;
• custom Nova fields and tools;
• an older PHP runtime that needs its own upgrade;
• front-end build tooling, such as Laravel Mix moving to Vite.

A well-tested application on a recent version, with mainstream packages, can move one major as routine maintenance. An application several versions behind, with abandoned packages and no tests, is a project. Our statements of work cover upgrades from Laravel 8 to 13 and from 11 to 12, with Nova upgrades alongside, and what separates the two cases is the code around the framework, not the framework.

When to rebuild instead

Upgrade when the code is understandable and the tests, or at least the behaviour, can be pinned down. Consider a rebuild, in whole or in stages, when:

• most of the packages are abandoned and no replacement fits;
• the application predates framework conventions and fights them;
• nobody can say what it does, and nothing can be tested;
• the business needs have changed more than the version has.

Even then, the safer route is usually to rebuild in stages behind the running system. We describe that trade-off in inheriting a legacy PHP application. For our Laravel development clients, the first step is a short audit that says which of the two the application needs.

If you would rather hand the whole job over, see our framework upgrades service, which also covers Drupal, React Native and PHP versions.

Sources: Laravel 13.x release notes, Laravel 9.x release notes (9 and 10 dates), upgrade guides for 13.x, 12.x, 11.x and 10.x, PHP supported versions, Nova 5 installation and Nova upgrade guide, checked November 2026.