Laravel version upgrades, done in reviewable steps.

Move off an unsupported Laravel or PHP version without a big-bang rewrite: a compatibility report first, then the upgrade itself in small pull requests you can review and roll back.

Signs this is the right engagement

  • You are on a Laravel or PHP release that no longer gets security fixes.
  • A package you depend on is abandoned and blocking the upgrade.
  • A previous upgrade attempt was abandoned halfway.

What you get

Compatibility report — Every breaking change between your version and the target, mapped to the files in your codebase that are affected.

Dependency migration — Composer packages moved to maintained releases, abandoned packages replaced, and PHP version raised to a supported branch.

Step-by-step upgrade — One version at a time, each as its own pull request with a working test run, so a failure never leaves you stranded between versions.

Deprecation cleanup — Removed helpers, changed config keys and renamed facades resolved rather than silenced.

Post-upgrade smoke checks — A documented pass over authentication, billing, queues, scheduled jobs and mail before the branch is merged.

How the engagement runs

  1. Read-only access: You share the repository and a staging environment. No production changes are made until scope is agreed in writing.
  2. Written scope and fixed price: You get the deliverable list, the price and the delivery date before you pay anything. If it is not on the list, it is not in the sprint.
  3. Build in the open: Work lands in small pull requests against your repository with commit messages you can read. You own the code from the first commit.
  4. Handover: Written summary, migration and deployment notes, and a prioritised list of anything found but deliberately left out of scope.

Price and timeline

Laravel Upgrade Service: from $1,000. Typical delivery 1–3 weeks.

Scope, price and delivery date are agreed in writing before any payment. Work is delivered as reviewable pull requests in your own repository, and you own the code from the first commit.

Frequently asked questions

How far back can you upgrade from?
Older Laravel 5 and 6 applications are common starting points. Very old codebases are quoted after the compatibility report, because the honest answer sometimes is that a targeted rebuild costs less.
Will the site go down?
No. Work happens on a branch and a staging environment; production is only touched at an agreed cutover window with a rollback plan.
What if there are no tests?
Characterisation tests are added around the risky paths first — billing, authentication and anything money touches — so the upgrade can be verified rather than hoped for.
Is the compatibility report available on its own?
Yes, as part of the $299 Laravel Triage Audit. It is credited against the upgrade sprint if you book one within 30 days.

Related engagements

Stepwise upgrade off an unsupported Laravel and PHP release — The application runs on a supported Laravel and PHP branch, with a rollback plan that was written before the cutover rather than improvised during it.

Laravel upgrades: free tools, guides and proof

Every asset below feeds the same laravel upgrades cluster: run the free tool, read the guide, then see the proof page for a real engagement.

Laravel upgrade readiness scanner — Grade your current version against the supported release ladder.

PHP version compatibility checker — Find the PHP features that break on the version you are moving to.

composer.json validator — Spot the constraints that will block the upgrade.

Laravel version & EOL risk checker — See your support status and the upgrade hops between you and current.

Composer dependency conflict decoder — Decode the resolver errors an upgrade throws.

Other Laravel services

Laravel application takeover — Inherited an undocumented Laravel application, or the previous Laravel developer disappeared mid-project? One focused engagement to stabilize the deployment, take ownership of the codebase and fix the specific failure — with a written diagnosis before any code changes.

Performance — Slow endpoints, N+1 queries, queue backlogs and memory-hungry jobs — profiled with real data, fixed in priority order, and reported with the numbers from before and after.