Laravel upgrade service
Move an old Laravel application to a supported version, one tested step at a time.
Laravel upgrades are usually described as routine, and from one recent version to the next, they often are. But an application several versions behind, with abandoned packages, no tests and years of custom code, is a different job. I upgrade those, in stages, so the application keeps working at every step.
Book a free conversationLegacy System Assessment, from £2,500
Is your Laravel version still supported?
From Laravel's official support policy, checked October 2026. Always confirm at laravel.com/docs/releases.
| Laravel version | Needs PHP | Status |
|---|---|---|
| 13 | 8.3 - 8.5 | Current. Bug fixes to Q3 2027, security fixes to Q1 2028 |
| 12 | 8.2 - 8.5 | Security fixes only, until 24 February 2027 |
| 11 | 8.2 - 8.4 | End of life since 12 March 2026 |
| 10 and earlier | End of life |
Laravel gives each release 18 months of bug fixes and 2 years of security fixes. The upshot: Laravel 11 and everything before it no longer receives security patches, and Laravel 12 is now in its security-only period. Laravel 13 also needs PHP 8.3 or newer, so an upgrade often means a PHP upgrade too. PHP upgrades
Where are you starting from?
| Starting point | What the job usually involves |
|---|---|
| Laravel 11 or 12 | Often a small step. Laravel describes recent releases as minor upgrades for most applications, so the effort is mostly checking packages, PHP and your own code |
| Laravel 8, 9 or 10 | A multi-step upgrade: several major versions, a PHP jump, replaced components and package updates |
| Laravel 5, 6 or 7 | A larger project. Old PHP, old packages, old front-end tooling, and often a framework that was heavily customised |
| Older or heavily modified | An assessment first. Sometimes staged upgrade, sometimes staged replacement. Rewrite vs refactor vs upgrade |
How I upgrade Laravel applications
1. Assess
I map the framework version, PHP version, database, every Composer package, the front-end build, queues, scheduled jobs and integrations. I find the blockers before starting: abandoned packages, unsupported versions, hard-coded assumptions. AI-assisted analysis does this far faster than manual review, and every finding is checked by a person. How I use AI
2. Build a safety net
Most legacy Laravel applications have thin or no tests. Before changing the framework, I write tests around the behaviour that matters: orders, payments, reports, permissions. They tell us if an upgrade changes something it shouldn't.
3. Upgrade in steps
Major versions are upgraded in sequence, with the application working and tested at each stage, not in one leap. Automated tools can handle some of the mechanical changes, but they don't understand your business logic, so every change is reviewed.
4. Deal with the packages
Third-party packages often cause the real delay: abandoned, replaced, or tied to a specific Laravel version. I replace, update or remove them, and where needed, carry over what they did.
5. Test in staging and roll out carefully
The upgraded application runs on a copy of your environment for you to check. Deployment is planned for a quiet time, with a rollback ready.
6. Hand over
Documentation of what changed, a clear picture of what's now current, and a plan for keeping it current.
What typically causes trouble
- PHP version jumps. Each Laravel version needs a minimum PHP version, so the framework and PHP often have to move together.
- Abandoned or incompatible packages. The single most common cause of delay.
- Replaced components. For example, mail sending moved from Swift Mailer to Symfony Mailer in Laravel 9, and file storage moved to a newer Flysystem. Old code written for the previous component needs updating.
- Removed features. For example, the
$datesmodel property was removed in Laravel 10 in favour of$casts. - Front-end tooling. Older applications often use Laravel Mix, which has been replaced by Vite as the default.
- Tied-together packages. If you use Livewire, Filament, Nova, Horizon or Passport, their major versions are linked to the Laravel version and often to each other.
- Custom code that depends on framework internals, and tests that don't exist.
- Old server configuration, extensions and scheduled jobs.
None of this is exotic. It's predictable once you map it before you start, which is the point of the assessment.
Do you have to adopt the new project structure?
Not necessarily. Newer Laravel versions changed the default application skeleton, but an existing application can generally keep its existing structure. I'll tell you whether moving to the new structure is worth it for you, or just churn.
Upgrade or rebuild?
Most Laravel applications are good candidates for staged upgrade: the framework is well documented, upgrade paths are well trodden, and the code has usually been built on solid foundations. A rebuild is occasionally right. I'll tell you honestly which applies. Rewrite vs refactor vs upgrade
What it costs
Fixed price, after assessment. I can't honestly quote an upgrade for an application I haven't seen.
- Free conversation about the application and what's worrying you
- Legacy System Assessment, from £2,500: framework, packages, PHP, database, server and risks mapped
- Fixed-price quote for the upgrade, based on what was found. No obligation to continue
What affects cost: how many major versions behind you are, how many packages need replacing, test coverage, the size and age of the codebase, integrations and server complexity. Direct day rate is £950, with urgent work from £1,300 per day. Full pricing
For agencies
Got a client on an old Laravel version that your team doesn't want to touch? I can upgrade it white-label, or direct with you as referrer. Agency terms
Frequently asked questions
Which Laravel version should we upgrade to?
Usually the latest your PHP version and packages allow, which today is Laravel 13 where PHP 8.3 or newer is available. A version with a long support window means you won't be back in the same position next year.
Can we skip versions?
In practice, no. Upgrades are done one major version at a time, because each step has its own changes. The work is staged, but a good process makes each step small.
How long will it take?
It depends on how far behind you are, the number of packages involved and the amount of test coverage. I'll confirm a timeline in the fixed-price quote.
Will the site go down?
Not for the build. The work happens on a copy. The final switch is planned for a quiet time with a rollback ready.
We use Livewire, Filament or Nova. Is that a problem?
It's manageable, but it needs planning. Those packages have their own versions and upgrade steps, which have to line up with the Laravel version. I include them in the assessment.
Do you only work with Laravel?
No. I work with custom PHP and other frameworks too. PHP upgrades
Tell me what you've inherited.
Tell me your Laravel and PHP versions and what's worrying you. I'll tell you honestly what an upgrade involves.
Book a free conversationLegacy System Assessment, from £2,500