How to Upgrade Laravel to 13: Steps, Breaking Changes and AI Help

Which Laravel version are you on, and how many hops is that?

Find out first, because the number of major versions between you and 13 is the whole estimate. Run composer show laravel/framework in the project root. Laravel's release notes then tell you where that leaves you: bug fixes for 18 months and security fixes for 2 years from each major release.

Laravel 10 and 11 get no more security fixes at all; Laravel 12 has under four months left; Laravel 13 is covered until 17 March 2028.

Each major version has its own guide and estimate: the 10 to 11 guide says 15 minutes, the 11 to 12 guide 5 minutes, the 12 to 13 guide 10 minutes. Those cover the mechanical edits, not your code, packages or tests, which is where the hours go. Hop in order and commit after each one.

Does your server's PHP meet the Laravel 13 minimum?

Laravel 13 requires PHP 8.3 and supports up to 8.5. If you are on 8.2 that is a separate project to finish first, and it is the most common reason a Laravel 13 upgrade stalls. Pick the branch by how long it is supported. These dates are from the PHP supported versions page, read on 1 November 2026.

PHP 8.3 clears the bar but left active support on 31 December 2025, and 8.4 leaves it on 31 December 2026. By that test 8.5 has the longest runway, and Laravel 13 supports it. Composer's documentation shows prohibits working on platform requirements as well as packages:

composer prohibits php 8.5

Anything it lists will not install on that PHP version. Raising PHP on the server is its own job with its own risks, and I wrote that up in updating PHP on a server safely.

Will your packages let you move to Laravel 13?

This decides the schedule, and Composer answers it in one command. The Composer CLI documentation says prohibits, also spelled why-not, "tells you which packages are blocking a given package from being installed".

composer prohibits laravel/framework 13.0
composer prohibits laravel/framework 13.0 --tree

Run it before you edit anything. An empty result means nothing stands in the way. A list means each named package needs a newer release, a replacement or removal. --tree prints the chain, so you can see whether the blocker is one you chose or something three levels down. --locked reads composer.lock instead of the installed files.

Filament is the admin panel package I run into most often on Laravel projects, so check it directly.

The illuminate/contracts line decides whether Filament installs on Laravel 13, and both branches allow it. Plugins are the real risk: Filament's own upgrade guide warns that "some plugins you're using may not be available in v5 just yet" and suggests removing, swapping or waiting for them. If you are moving Filament too, its script does the repetitive edits:

composer require filament/upgrade:"^5.0" -W --dev
vendor/bin/filament-v5
# Run the commands output by the upgrade script, they are unique to your app
composer require filament/filament:"^5.0" -W --no-update
composer update

Do not run the Filament upgrade and the Laravel upgrade in the same commit. One at a time, tests in between, so a failure has one obvious cause.

Which upgrade route should you take: by hand, Shift or an AI agent?

Three routes exist, and the Laravel documentation names two of them. Pick on how many hops you have and whether your test suite is trustworthy.

The upgrade guide calls Shift "a community-maintained service that automates Laravel upgrades". Its prices are per major version, so an old app pays for each hop:

In figures, on the Shifts page on 1 November 2026: the Shift to Laravel 10.x costs $39, to 11.x $39, to 12.x $29 and to 13.x $19. A Laravel 11 app therefore pays $48 to reach 13 and a Laravel 10 app pays $87. The same page offers purchasing power parity pricing in some countries, and lists a free Laravel PreShift that reports what your upgrade involves before you buy anything.

The AI route is newer. The upgrade guide calls Laravel Boost "a first-party MCP server that provides your AI assistant with guided upgrade prompts": install it in a Laravel 12 app, then run the /upgrade-laravel-v13 slash command in Claude Code, Cursor, OpenCode, Gemini or VS Code. It needs laravel/boost ^2.0.

composer require laravel/boost --dev
php artisan boost:install

The Boost documentation lists what the agent gets: MCP tools that read your PHP and Laravel versions, installed packages, schema, last error and recent log entries, plus a documentation API with "over 17,000 pieces of Laravel-specific information", so the agent checks the version it is editing instead of guessing. Run php artisan boost:update after the bump so the guidelines match, and keep the agent in a reviewable loop, as in my Claude Code workflow for client projects.

How do you run the Laravel 12 to 13 upgrade?

Edit the constraints in composer.json, run composer update, then walk the breaking changes. The guide's high-impact dependency edits:

If you also create new apps on that machine, the guide says to refresh the installer with composer global update laravel/installer, or update Herd. Start from a fresh branch and a green suite: on a red suite you cannot tell which failures the upgrade caused.

Which Laravel 13 breaking changes actually bite?

The quiet ones cause more trouble than the loud ones. Laravel grades every documented change by likelihood of impact, and says the focus of this cycle was "minimizing breaking changes", so most applications upgrade without much code moving.

Two more bite after deployment rather than during it.

• Session serialization. The Laravel 13 skeleton sets serialization to json in config/session.php. The guide is explicit: syncing that file and changing php to json "will invalidate all active user sessions". Keep php to upgrade without logging everyone out, or move to json deliberately and warn your users.
• Global helper collisions. Laravel 13 depends on symfony/polyfill-php85, which on PHP below 8.5 defines array_first() and array_last(). The guide warns these can conflict with laravel/helpers or your own helpers, and that the historical array_first() took a callback while the polyfill version does not. Use Arr::first() instead.

Lower down sit changes that only show up in tests: Container::call respects nullable class defaults, custom Str factories reset between tests, domain routes take precedence over non-domain routes, and Js::from uses unescaped Unicode. None break a boot; all can turn a passing assertion red.

How do you test and ship the upgrade without breaking production?

Treat it as a deployment, not a maintenance task. This is the checklist I work through on a client Laravel upgrade.

• Branch from a green suite on the version you run today.
• Back up the database and confirm you can restore it somewhere else.
• Upgrade PHP on its own, and run the suite before touching Laravel.
• One major version per commit, with composer prohibits laravel/framework <next>.0 before each.
• Diff config/ against the Laravel 13 skeleton and decide each change on purpose, above all session.php and cache.php.
• Exercise what tests rarely cover: login, password reset email, payment webhook, queue worker, scheduled commands, uploads.
• Deploy to staging on production's PHP version and run the queue and scheduler there for a day.
• Ship in a low-traffic window with the previous release ready to redeploy.

Check the database too. Laravel's database documentation lists first-party support for MariaDB 10.3+, MySQL 5.7+, PostgreSQL 10.0+, SQLite 3.26.0+ and SQL Server 2017+. The DELETE change is the one to watch: Laravel 13 compiles ORDER BY and LIMIT into joined deletes, and the upgrade guide names MySQL, and MariaDB before 11.8.1, as engines that do not support that syntax and may now throw a QueryException instead of running an unbounded delete.