Laravel 10 to 11: do you have to adopt the new skeleton?

The Laravel 11 upgrade guide is direct: “we do not recommend that Laravel 10 applications upgrading to Laravel 11 attempt to migrate their application structure, as Laravel 11 has been carefully tuned to also support the Laravel 10 application structure.”

So your app/Http/Kernel.php, app/Console/Kernel.php, exception handler and service providers can stay where they are. So can the config files you’ve already published. Tutorials about bootstrap/app.php describe new applications, and if your project doesn’t look like theirs, nothing is wrong.

It’s an optional tidy-up, so treat it as a separate job, if you do it at all. Mixing it into the version upgrade makes a large diff, and when something fails you can’t tell which change caused it. It can be worth doing later if you’re starting a long period of new development and want new hires to see what the current docs show. If the application is stable and mostly maintained, we’d leave it alone: it adds risk and doesn’t change what your users get.

The guide lists these updates. In the “stops supporting” cases, such as Passport 11 and Sanctum 3, Composer won’t let you keep the old major on Laravel 11.

The Livewire row can be most of the project. If you’re on Livewire 2, or on Filament 2, which needs it, that’s a major front-end upgrade hiding in a framework bump. See the package compatibility matrix and our Filament upgrade path.

Cashier Stripe, Passport, Sanctum, Spark Stripe and Telescope stop loading migrations from their own folders. On an existing database the tables are already there, so nothing looks wrong. The issue appears the next time someone runs migrations from empty: a new developer, a CI run or a staging rebuild. Tables are missing, and the error points nowhere near the upgrade. Publish them during the upgrade:

php artisan vendor:publish --tag=sanctum-migrations
php artisan vendor:publish --tag=passport-migrations
php artisan vendor:publish --tag=cashier-migrations
php artisan vendor:publish --tag=telescope-migrations

Then test it for real. Point the application at an empty database, run php artisan migrate, and check that the tables match production. Published files carry fresh timestamps, so on an existing database they’ll show as pending and can try to create tables that exist. Check that behaviour on a copy of production before you release.

Our Laravel 10 guide covers the headline breaking changes, including the rule that a change() call must now restate every attribute it wants to keep. It’s worth knowing how to find them:

grep -rn -- "->change()" database/migrations

This only matters for migrations that will run again. Those already applied in production have done their work. But a fresh install replays them all, under the new rules, so the columns it builds can differ from production without any error. Laravel’s suggested way out is php artisan schema:dump, which squashes the history into a single schema file. Run it from a database that matches production, not from a developer’s copy.

• spatie/once. Laravel 11 has its own once function, so the guide says to remove this package to avoid a conflict.
• doctrine/dbal. Laravel no longer depends on it, and methods such as getDoctrineSchemaManager() are gone. Use Schema::getColumns() and its neighbours.
• Password rehashing. Passwords are rehashed at login when the work factor has changed. If your User model’s password column isn’t called password, set authPasswordName or turn rehashing off with rehash_on_login.
• A model relationship named casts. The base model now has a casts method, so a relationship with that name conflicts.
• Spatial columns. Methods such as point() and polygon() give way to geometry() and geography().
• MariaDB. There’s now a dedicated mariadb driver. It’s optional, but if you switch, its uuid column type is native, so existing migrations need a look first.
• Cache key prefixes. Redis, Memcached and DynamoDB prefixes lose their automatic :. Add it back if you don’t want existing keys to miss once after the release.

1. Move PHP to 8.3 on Laravel 10 and release that alone. Both framework versions accept it.
2. Update whatever can move while still on Laravel 10, one package per release.
3. Change the framework and required package majors together, leaving your structure alone.
4. Publish package migrations, and test both a fresh install and a copy of production.
5. Don’t stop there. Laravel 11 is already past its security window, so continue with 11 to 12 and 12 to 13, ideally in the same project.

Our Laravel upgrade service prices the whole path as one job, after a free assessment. If you’re weighing that against doing it yourself, the cost guide shows our published prices.