Laravel 11 stopped getting security fixes on March 12, 2026. Laravel 10 stopped on February 4, 2025. If your app runs on either, you are running a framework that no longer gets patches, and every month you wait makes the upgrade bigger.
The first question we hear is "what will it cost?" The framework is rarely the expensive part. The cost sits in the things around it: how many versions you skip, which packages died along the way, and whether anything tests the code you are about to change.
This post shows what moves the price of a Laravel upgrade, in what order we work, and how to keep it small. Our upgrades start from $5k. Where the number lands above that depends on the factors below, and we check them before we quote.
Where your version stands today
Laravel supports each major version with bug fixes for about 18 months and security fixes for two years. This is the current table from the Laravel release notes:
| Version | PHP | Security fixes until |
|---|---|---|
| 10 | 8.1 to 8.3 | Feb 4, 2025 (ended) |
| 11 | 8.2 to 8.4 | Mar 12, 2026 (ended) |
| 12 | 8.2 to 8.5 | Feb 24, 2027 |
| 13 | 8.3 to 8.5 | Mar 17, 2028 |
If you are on 12, you have until February 2027 and no emergency. If you are on 11 or older, the clock has already run out. Laravel 13 needs PHP 8.3 or higher, so the PHP version on your servers is part of the job too.
What moves the cost
These are the factors we look at in every upgrade check. None of them is about Laravel itself.
| Factor | Smaller upgrade | Bigger upgrade |
|---|---|---|
| Versions to cross | One major version | Three or four, done one at a time |
| Packages | All maintained, with releases for the target version | Abandoned packages that need replacing or forking |
| Test coverage | Feature tests on login, payments and reports | None, so we write them first |
| PHP and server | Already on a supported PHP | Old PHP, old OS, manual deploys |
| Custom code | Follows Laravel conventions | Core classes overridden, logic in controllers |
| Release process | Pipeline with rollback | Files copied to a server by hand |
The rows interact. An old app with no tests and a dead payment package costs far more than the sum of its parts, because every fix has to be verified by hand.
Packages are where surprises live
Run composer outdated and look at what has no release for the version you want. A package that has not been updated in two years, and holds your payments, PDFs or admin screens together, is the usual source of surprise cost. The options are to replace it, to fork it, or to rewrite the part of your app that depends on it. Each has a price, and we want to know which one before we quote.
This is why we ask for your composer.lock first. It lists every package and exact version. From it, we can tell you which versions you cross, which packages block you and what the path looks like.
Tests decide how risky the upgrade is
An upgrade changes the code underneath your app. Without tests, you find out what broke when a customer does. With tests, you find out in minutes, before anything ships.
On Marafiq, a training platform we built on Laravel 13 with a team of 2, about 940 automated tests run on every change. That number is why we can move a dependency and know the same day whether certificates, checkout or quizzes still work. You can read how it was built in the Marafiq case study. Marafiq was built on 13 from the start, so it is proof of our testing habit, not of an upgrade we ran. Your app will not begin near 940 tests, and it does not need to.
Take a hypothetical case: a SaaS with 300 customer accounts, on Laravel 10, with Stripe billing through a package that stopped updating. Two things decide the bill. The first is how many versions sit between 10 and the target, since each one is its own round of fixes and testing. The second is whether anything covers the billing flow. If a test already creates a subscription and checks the invoice, we can replace the package and know it works. If not, someone has to write that test first, and that work is part of the price.
If your app has no tests, the first step is feature tests around the flows that handle money or data: login, checkout, invoicing, permissions. This adds cost up front. It also pays for itself, because every later change gets cheaper to verify. The same approach is in our post on modernizing a legacy Laravel app without a rewrite.
The order we work in
Upgrade check. We read
composer.lockand the PHP version, and list the blockers.Tests on critical paths. Only where they are missing.
Pipeline. Tests run on every push and a release can be rolled back, before any version changes.
One version at a time. Each major version goes to staging, then to production, before the next starts.
Replace dead packages in the step before the one that breaks them.
Hand-over. You get a short note on what changed, what we replaced and what to watch.
Skipping versions in one jump looks cheaper on paper. It is usually the opposite: when something breaks, you cannot tell which version broke it.
Ways to keep it small
Upgrade before the support date, not after. If you are on 12, a planned upgrade in the next few months costs less than an emergency one in 2027.
Remove what you do not use. Dead packages and unused features cost nothing to delete and a lot to port.
Freeze features during the upgrade window. New work on old code during the upgrade means merge conflicts and re-testing.
Keep your structure. Laravel's upgrade guides let older apps keep their existing layout. Upgrade first, restructure later.
Use the automated tools. Rector and similar tools do the mechanical changes. A developer still reviews their output.
When an upgrade is the wrong answer
Sometimes the cheapest option is to leave the app alone for now. A small internal tool with no sensitive data and no public access can wait, if it sits behind a firewall and you accept the risk. And sometimes the schema is wrong at its core, and upgrading code on top of it only delays a rebuild. We say so after the upgrade check, and we would rather tell you that than sell you a $5k job you do not need.
If you are comparing teams for this work, our posts on fixed price vs. time and materials and what to ask a software agency cover how to read a quote and what to ask before you sign.
Next step
Book an intro call and bring your composer.lock. We will tell you which versions you cross, what blocks you and what drives the cost for your app. Upgrades start from $5k, and we quote after the check. Book the call.