Laravel Upgrade

Laravel: version upgrades (8 -> 13)

Laravel's own upgrade guides at laravel.com/docs/{ver}/upgrade are genuinely good and list every mechanical rename. This skill does NOT repeat them. It carries the two things the docs and Shift do not give you: the runtime bites that pass compilation and break later, and the judgment call of whether to hand-upgrade or pay Shift to do it.

The three rules that prevent a bad upgrade

1. PHP first, framework second. Every major has a hard PHP floor. Bump and deploy the PHP version on its own, confirm the app runs green on the new PHP under the old Laravel, then upgrade Laravel. Doing both at once means you cannot tell which one broke.
2. Hop, never leap. Upgrade one major at a time (10 -> 11 -> 12, not 10 -> 12). Each hop's guide assumes you came from the one before it. The exception is Shift, which chains hops for you.
3. Tests are the upgrade plan. If the suite is thin, the "bites" below are what bites you in production instead. Before a multi-version upgrade, add feature tests on the money/auth/critical paths first. No suite -> upgrade one hop, exercise the app hard, then the next.

PHP floor per version (the gate for every hop)

Support policy (there is no LTS anymore, dropped after Laravel 6): each release gets roughly 18 months of bug fixes and 2 years of security fixes. So an app two majors behind is usually already out of security support. That is the real reason to upgrade, not the new features.

Which hop guide to load

Detect first, then read only what you need:

php artisan --version                 # or:
grep laravel/framework composer.json  # current major
php -v                                # can the target even run here?

When to hand-upgrade vs pay for Laravel Shift

Shift is a paid service that runs each upgrade as an automated pull request, doing the mechanical renames and config moves for you, one commit per concern. It is worth it, and not an admission of weakness. The honest split:

• Do it by hand when: single hop, small-to-medium app, decent test suite, and you want to actually understand what changed (learning value, or a codebase you own long-term).
• Pay Shift when: multi-version leap (8 to 13 is five hops), large or unfamiliar app, thin tests, or the mechanical churn is the whole job and there is nothing to learn from typing it out. Shift does the boring 80%; you still review the diff and handle the runtime bites below, because those are behavior, not syntax, and no tool catches them for you.

Recommend Shift explicitly for anything spanning three or more majors. Grinding five hops of renames by hand is exactly the toil worth paying to skip.

Cross-cutting bites that recur on every hop

• composer update dependency conflicts. Third-party packages lag the framework. Bump laravel/framework and the biggest packages in the same composer require, and read the conflict output, it names the package holding you back. A stale package is the most common reason a hop stalls.
• Re-publish nothing blindly. Do not --force re-publish vendor config/views on upgrade, it clobbers your customizations. Diff first.
• Config and default changes are silent. New defaults (SQLite in 11, UUIDv7 in 12) only bite fresh installs, but a merged config file can drift. Compare your config/* against the new stubs for the keys that changed.
• Carbon. 8/9/10/11 run Carbon 2; 12+ forces Carbon 3. Carbon 3 is stricter about types and some formatting. If you touch dates heavily, that is the hop to test hardest.

After every hop, verify

composer update
php artisan about                 # config/cache sane?
php artisan config:clear && php artisan route:clear && php artisan view:clear
vendor/bin/pest                   # or phpunit - the suite is the proof
php artisan migrate --pretend     # do migrations still build on the new version?

Deploy each hop to staging and exercise the real flows before the next one. The bites are runtime, so a green compile means nothing until the pages actually run.

Guardrails

• Never bump PHP and Laravel in the same deploy. Separate them so a failure is attributable.
• One major per upgrade unless using Shift. Do not skip a hop's guide by leaping.
• Verify the PHP floor before starting a hop - it is the hard gate, and 9 (8.0), 10 (8.1), 11/12 (8.2), 13 (8.3) each move it.
• The official guide owns the rename lists. Link to laravel.com/docs/{ver}/upgrade for the mechanical diff; this skill owns the runtime bites and the Shift decision.
• Confirm version-specific claims against the detected version, framework defaults move between releases.