How Much a Laravel Version Upgrade Costs

What actually drives the price of a Laravel upgrade — how many major versions you are behind, PHP compatibility, package churn and test coverage — with realistic ranges instead of a single made-up number.

"How much to upgrade our Laravel app?" is an unanswerable question until four things are known. This article explains what those four things are, why each one moves the number, and what realistic ranges look like.

The four cost drivers

1. How many major versions you are behind

Laravel's own upgrade guides are excellent, and single-hop upgrades on a maintained app are frequently a one-day job. Cost is not linear with distance, though: each hop compounds because your packages must also support both ends of the jump. Going 8 → 9 → 10 → 11 is not three times the work of 8 → 9; it is closer to five times, because intermediate states have to boot and pass tests.

2. PHP version compatibility

An upgrade is usually two upgrades. Laravel 10 requires PHP 8.1+, Laravel 11 requires 8.2+, Laravel 12 requires 8.2+. If you are on PHP 7.4 or 8.0, the PHP jump brings its own work: removed extensions, stricter type coercion, ext-mcrypt remnants, and libraries that quietly relied on deprecated behaviour. Server-level PHP upgrades also mean touching your provisioning, not just your code.

3. Package churn

This is where budgets die. Every abandoned or fork-dependent package is a decision: replace it, fork it, or inline the parts you use. Common offenders include old PDF generators, payment SDKs predating Cashier, homegrown permissions packages, and admin panels from the pre-Filament era. Two abandoned packages can cost more than the entire framework upgrade.

4. Test coverage

With a real suite, upgrading is mechanical: change constraints, run tests, fix what breaks, repeat. Without one, every change must be verified by hand, and the honest approach is to write characterisation tests for the money paths first. Budget the tests — do not pretend the upgrade is cheaper by skipping them.

Realistic ranges

These are ranges, not quotes. They assume a single senior engineer and a codebase of moderate size.

Situation — Typical effort — Typical cost

One major version behind, tests pass, packages current — 1–3 days — Included in a rescue sprint from $1,000

Two versions behind, PHP jump, a few package swaps — 1–2 weeks — $1,000–$2,500

Three or more versions behind, no tests, abandoned packages — 3–6 weeks — $2,500 and up, scoped in stages

Legacy app on PHP 7.x with vendored patches — Rebuild comparison required — Decided by audit, not by guess

If someone quotes an upgrade before reading your composer.lock, they are quoting an average, not your application.

What a quote should be based on

A defensible upgrade quote needs, at minimum:

  • composer.json and composer.lock
  • The output of php -v in production
  • Whether a test suite exists and what it covers
  • A list of the flows that must not break

Our free Laravel upgrade readiness scanner reads a pasted composer.json and returns the hops required, the PHP floor and the packages most likely to block you — in about thirty seconds, without contacting anyone.

Doing it in stages

Big-bang upgrades are what make upgrades expensive. Stage the work instead:

  1. Add characterisation tests for the paths that earn money.
  2. Upgrade PHP to the highest version your current Laravel supports.
  3. Replace or fork blocking packages, one merge at a time.
  4. Take framework hops one at a time, deploying between each.
  5. Adopt the new defaults (config structure, middleware changes) after you are stable, not during.

Each stage is independently shippable, which means you can stop at any point with a working application — the property that makes an upgrade budgetable at all.

Next steps

Compare approaches in Laravel Shift versus a manual production upgrade, or get the version and dependency read written up formally with the $299 Laravel Triage Audit.