How much does a Laravel upgrade cost in 2026?

Most Laravel upgrade quotes are guesses, because the framework is rarely the expensive part. Moving the framework itself from one major version to the next is usually a day or two of mechanical work, and tools like Laravel Shift will do much of it for under $40 a step. What decides the real cost is everything bolted onto the framework: abandoned packages, a PHP version the server can't leave, custom code that leaned on behaviour a later release removed, and whether there are tests to tell you when something broke.

This guide walks through where each Laravel version stands today, what changes on the way to Laravel 13, where the hours go, and indicative ranges by starting point. If you would rather have someone read your codebase and give a fixed number, that is what our Laravel upgrade and rescue service starts with.

Where your Laravel version stands

Laravel gives each major release 18 months of bug fixes and two years of security fixes. Once security support ends, a vulnerability found in the framework is fixed only in newer versions, so an app left behind stays exposed.

So as of now: anything on Laravel 11 or older is running without security patches, and Laravel 12 has about five months of security fixes left. Laravel 13 is the version worth landing on, and it needs PHP 8.3 or newer, which on many older servers is its own piece of work.

What changes on the way to Laravel 13

Each major step has its own breaking changes, which is why an upgrade should move one version at a time with the app deployable after every step. The ones that cost the most time on older apps:

• Laravel 9: PHP 8.0 minimum, Flysystem 3 for file storage and Symfony Mailer replacing SwiftMailer. Custom storage drivers and anything that touched the mailer internals need rework.
• Laravel 10: PHP 8.1 minimum, and long-deprecated methods finally removed. Code that ignored deprecation warnings for years pays for it here.
• Laravel 11: PHP 8.2 minimum and a slimmer application skeleton. The old structure still works, so adopting the new one is optional and shouldn't be bundled into the upgrade.
• Laravel 12: a light release for most apps; the main break is dropping Carbon 2 in favour of Carbon 3, which touches date handling.
• Laravel 13: PHP 8.3 minimum. For apps already on 12 this is usually the cheapest step of all.

The framework's own upgrade guide lists every change with an impact rating. Read it for each step you're crossing and search your codebase for the high-impact items before estimating anything.

Where the hours actually go

Third-party packages are the biggest variable. A package that stopped being maintained at Laravel 8 has no version that installs on 13, so it has to be forked, replaced, or its job rewritten into your own code. Run composer outdated --direct and look at each package's last release date: that list is a better cost predictor than the size of the app.

PHP is the second. Moving from PHP 7.4 or 8.0 to 8.3 surfaces deprecations, stricter type handling and removed functions across your own code, not just the framework's. It also often means a server change, and on shared or older managed hosting that can mean a migration.

Tests are the third, and they cut both ways. With a decent test suite, each step is apply, run, fix, deploy. Without one, every step needs manual checking of the flows the business depends on, and the sensible first job is writing a small set of smoke tests around checkout, login, billing or whatever pays the bills. That adds days up front and saves weeks of chasing regressions.

Finally, front-end build tooling. Apps still on Laravel Mix usually move to Vite during the upgrade, and older Vue 2 or jQuery front ends can turn a backend upgrade into a front-end project if you let them. Keep them separate unless there's a reason not to.

Indicative cost by starting point

The cheapest upgrade is the one done every year. An app kept within one major version of current rarely needs more than a few days per release, which is why ongoing maintenance usually costs less than a big upgrade every three years.

How to scope it before anyone quotes

1. Note the current Laravel and PHP versions, and what PHP versions your host can run.
2. List direct Composer dependencies with their last release dates, and mark any that look abandoned.
3. Count the tests and check they pass today. A red suite before the upgrade tells you something important.
4. Write down the five flows that would cost money if they broke. Those become the smoke tests.
5. Decide what is out of scope: skeleton restructuring, front-end rewrites and new features belong in separate pieces of work.

With those five answers, an honest developer can give a fixed price per version step instead of an open-ended hourly estimate. Without them, any number you get is padded for risk or will grow later.