How Much Does a Laravel Upgrade Cost? Prices by Version Gap (2026)

A Laravel upgrade typically costs €300-1,000 when your app is one version behind and has automated tests, and €2,500-8,000 when it's two or three versions behind, excluding VAT. Beyond that, Laravel upgrade cost depends less on Laravel itself than on your PHP version, your packages and whether there are tests, and an app on Laravel 9 or older can easily need €8,000-25,000 of work.

I do Laravel upgrades myself, so weigh my numbers with that in mind (and read the section on when you shouldn't pay anyone to do it).

The short answer: Laravel upgrade cost by version gap

Almost all of the price comes down to how far you are from the latest version and how easy the code is to test. Here are my rough estimates.

The hours assume a typical business app with user accounts, a couple of integrations and a handful of third-party packages, upgraded by an experienced developer. I've used €100 an hour, which isn't my rate. It's a round number inside the €75-120 range that Lancebase reports for freelance full-stack developers in Western Europe, so you can scale it to any quote you get. Scandinavian rates usually sit at the top of that range or above it, as I explain in my post on what freelance developers charge in Denmark.

For comparison, Laravel says it strives to make every major upgrade possible in one day or less, and the official 12 to 13 upgrade guide estimates 10 minutes. That holds for the framework in an app close to Laravel's default setup. My numbers are higher because they include packages, PHP, testing and deployment, which is where the time goes in an app with a few years of history.

An upgrade is one line in the budget for running software. For the bigger picture, see my European guide to software development cost.

What makes an upgrade cheap or expensive

The version gap is the obvious factor, but it's rarely the only one. These come up again and again:

• The version gap. Every major version has its own upgrade guide, and you have to work through them in order.
• PHP. Laravel 13 needs PHP 8.3 or newer, and PHP 8.2 only gets security fixes until December 31, 2026. If your server runs something older, PHP has to move as well, and sometimes that means a new server.
• Tests. With an automated test suite, a developer knows within minutes whether something broke. Without one, every key flow has to be clicked through by hand after each step. In my estimates, this is the single biggest factor.
• Third-party packages. Each package has to support the new version too. When a maintainer has abandoned one, it has to be replaced or rewritten, and that can cost more than the framework upgrade itself.
• Patched or unusual code. Edits inside vendor files, overridden framework internals and very old patterns slow every step down.
• Front-end build tools. An app still building its JavaScript and CSS with Laravel Mix rather than Vite may need that switched too.
• Whether the developer knows the code. Someone who already maintains the app can start right away. A new developer needs time to learn the setup, from a few hours on a small app to days on a large one.

These factors compound. Four versions behind, no tests and two abandoned packages is where estimates get wide, and where a short paid audit before the quote is money well spent.

Shift, AI tools or a developer: who does what

There are three ways to get an upgrade done, and they work best together. Laravel Shift is an independent service that Laravel's own upgrade guide points to. It automates most of the upgrade and opens a pull request for your developer to review. On Shift's own price list, a version step costs $19-39 as of October 2026. The same guide also mentions Laravel Boost, a first-party AI tool with a guided upgrade from 12 to 13.

A good developer will use Shift or similar tools, and you shouldn't see that as cutting corners. It moves the hours from routine edits to the parts that need judgment: packages that won't follow, testing, and a release you can roll back. It's also why the numbers in my table don't drop to zero just because the tool is cheap.

Fixed price or hourly: getting a quote you can trust

A single step in an app the developer already knows is easy to price up front. A multi-version jump in an unfamiliar codebase isn't, until someone has looked at the code. Here's what I'd recommend:

• One step in a known app: a fixed price straight away.
• Several steps or unknown code: a short fixed-price audit first, typically 2-6 hours, then a fixed price per step.
• A very old app with no tests: the audit should also answer whether upgrading or modernizing is cheaper.

Pricing per step has a side benefit. Each step can ship on its own, so the app stays live throughout, and you can pause between steps if the budget gets tight.

A quote worth signing should cover these seven things:

1. An audit of the Laravel, PHP and package versions.
2. PHP and server changes on staging and in production.
3. Dependency updates and replacements for abandoned packages.
4. The code changes from each upgrade guide.
5. Automated tests plus manual checks of key flows such as login, payments and email.
6. A release with a fresh backup and a rollback plan.
7. A period after release in which bugs caused by the upgrade are fixed at no extra cost.

To put that quote together, a developer needs your production Laravel and PHP versions, access to the repository (or at least composer.json and composer.lock), whether tests exist, where the app is hosted, which integrations it uses, and any hard deadline. If you're collecting several quotes, check that they cover the same ground. My guide to comparing software development quotes walks through how.

Why small yearly upgrades cost the least

Laravel ships a new major version roughly once a year. Under its support policy, each version gets 18 months of bug fixes and two years of security fixes. In practice, that means your app can be at most one version behind before it stops receiving security patches.

The numbers below are made up, but the pattern is typical. Picture a business app with user accounts, payments, a handful of packages and some tests, over four years:

Why does the jump cost more than the sum of its steps? Because the problems from each step pile up and have to be solved together. PHP has to climb several versions, some packages were abandoned along the way, and when something breaks, it's hard to tell which step caused it. Then there's the cost that never shows up on an invoice: the years the app ran without patches. If you sell to larger European companies, their security questionnaires often ask whether you run supported software, and with NIS2 putting supply-chain security on the agenda, expect that question more often.

My overview of the Laravel version support policy lists the end dates for every version. If you'd rather have upgrades handled as part of an ongoing arrangement, a retainer can cover them, and my guide to developer retainer agreements explains how those work.

When an upgrade isn't worth paying for

I make money from upgrades, so it's only fair to say when your budget is better spent elsewhere:

• The app will be shut down or replaced within a few months. Restrict access, keep the server patched and monitor it until it's switched off.
• You have an in-house developer who knows Laravel. A single step in an app with tests is a manageable job with the official guide and Shift.
• The app is so old that a step-by-step upgrade costs more than modernizing. That's often the case with Laravel 5 apps without tests, where large parts get rewritten along the way anyway.
• It isn't a Laravel app. Then these numbers don't apply, and you need a specialist in whatever it's actually built with.

One piece of advice the other way: don't save the upgrade to ship alongside your next big feature. Two large changes at once make both harder to test and more expensive to fix when something fails.

Next steps

Start with two version numbers: Laravel and PHP in production. With those and the table at the top, you'll know if it's a small step or a project.

1. Find the versions. Your developer or hosting provider can tell you in minutes.
2. Check them against the support dates, and put the end of security fixes in your calendar.
3. If you're more than one version behind, get an audit and an estimate per step.
4. Put future upgrades on a fixed yearly rhythm, ideally within six months of each new release.

If you'd like help with the work itself, here's how I handle Laravel development, upgrades and ongoing work. You deal directly with me, the person writing the code, you own the code from day one, and you'll hear back within one business day. I'm based in Denmark on Central European Time, so my working day overlaps with UK and EU business hours.

Frequently asked questions

Can I skip straight to the latest Laravel version?+

Not in one move. Each upgrade guide starts from the previous version, so an app on Laravel 9 has to go through 10, 11 and 12 to reach 13. You can bundle the steps into one project and release only at the end, but the work for each step doesn't disappear. I prefer to release each step separately, because it makes it obvious which change caused a problem.

How long does a Laravel upgrade take?+

A single step usually takes 1-3 working days from start to release, including testing. A jump across several versions more often takes 2-8 weeks, because every step needs testing and your team has to set aside time to check the key flows. If there's a hard deadline, such as your host retiring a PHP version, say so up front so the plan can be built backwards from that date.

Will my app go down during the upgrade?+

Usually not, or only for a few minutes. The work happens on a staging environment, and with the right deployment setup the release itself can often go out with no downtime. Moving to a new server or upgrading PHP may need a short, planned maintenance window, typically outside business hours. Make sure there's a fresh backup and a rollback plan before anything goes live.

Does GDPR require me to keep Laravel up to date?+

Not by name. No EU law requires a specific framework version. But if your app handles personal data, Article 32 of the GDPR asks for security appropriate to the risk, taking current technology into account, and a version with known, unpatched holes is hard to defend after a breach. If NIS2 applies to your business, the bar is higher still. Check with a legal adviser if you're unsure what applies to you.

Who pays if something breaks after the upgrade?+

That should be agreed before work starts. A sensible fixed-price quote covers bugs caused by the upgrade itself for a period after release, for example 14-30 days. Bugs that already existed and new functionality aren't included. Get it written into the quote, so there's no argument on the day something stops working.