Laravel maintenance & upgrades: keeping your application secure and current

The uncomfortable truth about Laravel applications: they keep working flawlessly long after they've stopped getting security updates. Nothing breaks, nothing flashes red, nobody complains. That's exactly why projects on Laravel 8 or 9 regularly land with us — four, five years old, in daily use, without a single patch since go-live.

Short version: Laravel ships a major release every year. Each version gets bug fixes for 18 months and security updates for two years. After that you're on your own. Update regularly in small steps and you pay manageable amounts during normal operation. Wait, and at some point you pay for an upgrade project.

Laravel's release cycle — what "supported" really means

Laravel has a pleasantly predictable rhythm: one major release per year, usually in the first quarter. The official support rule is the same for every version — 18 months of bug fixes, 24 months of security updates from release.

Two things jump out of that if you're reading it in summer 2026:

Laravel 11 has been completely out of support since March 2026. If a security hole in the framework is found tomorrow, you won't get an official patch for it. Anything below that — Laravel 10, 9, 8 — even less so.

Laravel 12 loses its bug fixes in mid-August 2026. Security updates do run until February 2027, but from then on: bugs in the framework won't be fixed for that version anymore.

Then there's the second clock a lot of people miss: PHP itself. Every PHP version gets two years of active support and then two years of critical security fixes only. PHP 8.1 finally ran out at the end of 2025, PHP 8.2 follows on December 31, 2026. If your Laravel is too old for a modern PHP, at some point your host can't run you on a supported PHP version anymore — and then the upgrade stops being voluntary and becomes urgent.

What happens when you let upgrades slide

"It works, doesn't it" is a deceptive state. What builds up in the background is something we see in project takeovers almost always in the same order.

1. Unpatched security holes. Laravel vulnerabilities are rare, but they exist — and they get publicly documented as soon as they're fixed. From that moment the weakness is readable by anyone, and every installation below the patch level is a known target. In practice the dependencies are more critical anyway: an average Laravel project brings 60 to 100 packages with it. Those get security updates too, and they age too.

2. Your host pulls the floor out. Managed hosts eventually shut off old PHP versions — for good reason. If your application only runs on PHP 8.1 and the server moves to 8.3, it stops. That's the call that will reach you on a Friday afternoon, guaranteed.

3. Ecosystem standstill. New versions of packages you need — payment providers, PDF generators, Excel export, monitoring — require current Laravel versions. Eventually you can't update a package without updating the framework. From then on you're blocked, and on exactly the change you urgently need.

4. Four small steps turn into a big bang. That's the most expensive point. An upgrade from Laravel 12 to 13 is usually a matter of a few hours to a day and a half for a well-maintained application. A jump from Laravel 8 to 13 skips five major versions, each with its own breaking changes, plus two PHP jumps. That's not an update anymore, that's a project with testing, sign-off and a risk phase — and it easily costs ten times the sum of the individual steps.

That calculation is the real reason we argue so stubbornly for ongoing maintenance — the general version of that argument is in why software maintenance matters.

What good Laravel maintenance includes

"Maintenance" is a vague word that can mean all kinds of things in a quote. With us it concretely contains this:

• Dependency updates. Regularly, not once a year. Patch and minor updates to packages get applied and backed up by the test suite. Security-relevant updates get pulled forward.
• Framework updates. Within a major version, Laravel updates are uncritical — those just come along. Major upgrades we plan together and tell you in good time when one is due.
• Monitoring. Errors in production shouldn't be reported by your users. We watch error rates, response times, failed background jobs and queue backlogs — before anyone calls.
• Backups that provably work. A backup that has never been restored is a hope, not a backup. We test the restore.
• Security patches with priority. When a relevant vulnerability becomes known, we don't wait for the next maintenance slot.
• Small improvements included. An extra field, adjusted copy, a new export — the things a ticket isn't worth. That's exactly what decides whether an application feels looked after or drifts away from reality after two years.

Not included are larger rebuilds and new modules. We bill those transparently by time — so everyone knows where they stand.

The upgrade path in practice

You don't do Laravel upgrades in one jump. The way from an old version to the current one goes version by version — 10 → 11 → 12 → 13 — and for a good reason: every step has its own officially documented upgrade guide with a list of breaking changes. Jump straight there and you combine the error sources of every intermediate step, and end up not knowing which change caused the problem.

Here's how we go about it:

1. Take stock. Which Laravel and PHP version is running, which packages are installed, how many of those are themselves outdated or no longer maintained at all? Are there tests? How much business logic hangs on spots that changed between versions?
2. Put up a safety net. If no tests exist — and with old projects that's the norm — we first write tests for the critical flows: login, checkout, invoice runs, whatever hurts at your place when it fails. That's effort, but it's the difference between "upgrade complete" and "upgrade complete, and we know it works".
3. PHP first, where possible. Often the PHP version can be raised before Laravel's turn comes. That untangles the debugging.
4. Version by version. Each step separately, each with a test run and its own commit. If something goes wrong, it's immediately clear which step was at fault.
5. Bring the dependencies along. Packages that are no longer maintained get replaced — often that's the most labor-intensive part, not the framework itself.
6. Staging, sign-off, go-live. With a fallback plan and the knowledge that the data migrations ran through cleanly.

The good news: Laravel has proven remarkably upgrade-friendly over the last few years. Breaking changes between major versions are usually manageable and well documented. The real risk almost never sits in the framework, but in your own code — in the places where someone worked around the conventions years ago.

What maintenance and upgrades cost

Clear numbers instead of hints:

• Ongoing maintenance: from €119/month. That covers updates, monitoring, security patches and small adjustments. Cancelable monthly, with a fixed point of contact — not a ticket hotline.
• Everything beyond that: €79/h. Larger rebuilds, new modules, involved upgrade projects. Billed transparently, traceable month by month.
• A single major jump on a well-maintained application with tests: in our experience half a day to two days.
• A catch-up project across three to five major versions with no existing tests: depending on size, more like 30 to 120 hours, a substantial part of that for the safety net.

That's exactly the math behind our maintenance argument: twelve months of maintenance cost you less than a single afternoon of crisis management plus the catch-up project that's coming anyway. How these amounts fit into an overall calculation is something we worked through in detail in what does Laravel development cost?.

Upgrade or rebuild — when is which worth it?

Not every old project is worth saving. Honest decision help:

An upgrade makes sense when the business logic is sound and the data model holds up, when the code halfway follows Laravel conventions, when the application works well day to day and is only technically behind. Then an upgrade is generally much cheaper than a rebuild — often a fifth to a third of the cost.

A rebuild makes sense when business logic is scattered across controllers and views, when central packages have been dead for years with no successors, when nobody can say what a section of code is supposed to do, or when the application has hit its limits in business terms anyway. In that case you'd be spending money on an upgrade to preserve a problem.

The hardest case is in between: sound in business terms, borderline technically. For that we do a short assessment with a clear recommendation and numbers for both paths — before you commit. If your current provider is no longer reachable for questions like this, our post on switching Laravel agencies is the right entry point; if it's about replacing a genuinely old system, you'll find the approach in replacing legacy software.

Bottom line: maintenance isn't a cost item, it's insurance

Laravel makes it easy to stay current — annual releases, clear support windows, good upgrade guides. The only prerequisite is that someone is paying attention. 18 months of bug fixes and two years of security updates are an honest offer, but they're also a deadline. Keep it in view and you pay small amounts during normal operation. Let it pass and you pay for a project later — and somewhere in between there might be an incident nobody needs.

Don't even know which Laravel version your application runs on? That's not an embarrassing question, that's the norm. As a Laravel agency we'll look at it together in a free first call: version, package state, security situation, PHP version — and afterwards you get an honest assessment of whether this is urgent or can comfortably wait until next year. No scaremongering, no sales pressure. If everything's fine, we'll tell you that just as clearly.

Frequently asked questions