Why Update Software Dependencies? The Real Cost of Waiting

Updating your framework and packages closes security holes that are already public, keeps you on versions that still receive fixes, and keeps the next upgrade small. That's the short answer to why you should update software dependencies. Skipping it doesn't make the bill go away: it grows every month, and it tends to arrive when something outside your control forces the issue.

I'm a freelance developer based in Denmark who maintains Laravel and JavaScript apps, so I have an obvious interest in you getting this done. Most of what follows works just as well for an in-house team.

The short answer

Not all updates carry the same risk. Here's how I typically handle the four kinds in a Laravel app.

The rule I recommend: apply patch and minor updates as they come. Move to a new major version within six months of its release. And never let a version run out of security support. Updates are only one part of keeping an app healthy after launch; the rest is covered in my web application maintenance guide.

What "dependencies" actually means

A modern web app isn't one program. It's your own code sitting on several layers of other people's code:

• The framework, such as Laravel or Next.js, which handles authentication, database access, routing and much more.
• Packages, the ready-made building blocks for payments, PDFs, image processing, email and so on. PHP pulls them in with Composer, JavaScript with npm.
• The runtime: PHP or Node.js, the language environment your code runs in.
• The server: operating system, database and web server.

What most non-technical owners miss is that packages have their own packages. Count those transitive dependencies and a fresh Laravel project pulls in somewhere around a hundred PHP packages, and the frontend often pulls in even more from npm. Any of them can get a security patch, and any of them can be abandoned by its maintainer.

Version numbers usually follow semantic versioning: three numbers, like 13.4.2. The last one (patch) means bug fixes. The middle one (minor) adds features without breaking existing code. The first one (major) is allowed to break things, which means your code has to be adapted. That's why major upgrades need planning and everything else can run on a schedule.

Five risks of outdated dependencies

Vulnerabilities become public knowledge

When a vulnerability in a package is found and fixed, it's also published. That's good news for everyone who updates and a recipe for attacking everyone who doesn't. From that moment, how to exploit the old version is no longer a secret.

OWASP, which maintains the most widely used list of web application security risks, groups vulnerable, outdated and unsupported components under A03:2025 Software Supply Chain Failures. In OWASP's community survey, exactly half of the respondents ranked it as the number one risk. The same page warns against treating patching as a monthly or quarterly chore, because that leaves you exposed in the meantime.

Support windows close

According to Laravel's own support policy, each major version gets 18 months of bug fixes and 2 years of security fixes. Laravel 11 lost security support in March 2026, and Laravel 12 follows in February 2027. PHP runs on a similar cycle of 2 years of active support plus 2 years of security fixes, and the official PHP support table shows PHP 8.2 reaching end of life on December 31, 2026.

An unsupported version doesn't stop working. It just stops getting patched, so the next vulnerability that turns up has no fix for you. I keep a separate, up-to-date breakdown of which Laravel versions still get security fixes.

One old version blocks everything else

Dependencies come as a chain. Laravel 13 requires PHP 8.3 or newer. A new version of your payment package may require a newer Laravel. At some point your hosting provider stops offering the old PHP version. Stand still in one place and you can't move anywhere else, including when a payment provider or third-party API retires the integration you rely on.

Compliance gets harder to defend

If your app handles personal data of people in the EU, GDPR Article 32 asks for security measures appropriate to the risk and to the state of the art. In my view, running software that no longer receives security fixes is hard to defend under that wording. If your company falls under NIS2, vulnerability handling is explicitly part of the required security measures, which I cover in more detail in what NIS2 means for web apps and their suppliers. For anything legal, check with an advisor.

Fewer people want to touch it

Documentation, forum answers and compatible packages for old versions get harder to find every year. My impression is that many developers either decline badly outdated projects or price the uncertainty into their quote. That's understandable, because on an outdated codebase even small changes take longer.

Small and often vs. big-bang upgrades

This is where the real cost difference lives. Laravel says it aims to make each major upgrade possible in one day or less. That's realistic when you move one version at a time and the app has tests. It isn't realistic when you're going from Laravel 8 to 13 in one go.

A big-bang upgrade means working through five upgrade guides back to back. At the same time PHP has to jump several versions, some packages have been abandoned, and failures from different steps get tangled together. It isn't five times the work of a single upgrade. It's often more, because you can't easily tell which step broke what.

My rule of thumb: a little every month beats a lot every three years. If the app is already on a very old version, modernizing can be cheaper than upgrading step by step, and I've written about the signs a legacy PHP system needs modernizing.

What not updating really costs

The cost of waiting rarely shows up on an invoice right away. It usually arrives in one of these forms:

• A forced upgrade under time pressure, because your host retires the old PHP version or an integration stops working. You pay for the same work, just with a tighter deadline and less room for testing.
• A security breach. On top of downtime and clean-up, a personal data breach generally has to be reported to your data protection authority within 72 hours under GDPR.
• Slower feature work. New features take longer when your developer has to work around old limitations or can't use current packages.
• A bigger bill later. The jump you postpone doesn't shrink. It grows with every major version released in the meantime.

Outdated dependencies are a textbook case of technical debt that gets more expensive the longer you wait.

A safe update routine in six steps

The order is the same for a small patch and a major upgrade. What changes is how long each step takes.

1. Take stock. Find out which version of the framework, PHP and Node.js the app runs. composer outdated and npm outdated list packages that are behind, while npm audit and Composer's audit command flag known vulnerabilities. Composer's audit also reports packages their maintainers have abandoned.
2. Prioritize. Security fixes first, then versions close to losing support, then everything else.
3. Build a safety net. Take a backup and have a staging environment that mirrors production. If the app has no automated tests, write at least a few covering login, payments and the flows customers use most.
4. Update in small steps. One major version at a time, following the official upgrade guide. Tools like Laravel Shift automate much of the mechanical work, but someone still has to review and test the result.
5. Test and release. Run the tests on staging, click through the critical flows, and release at a quiet time with a rollback plan ready.
6. Make it a routine. Apply security fixes as soon as they're out, book the remaining patch and minor updates monthly, and plan a major upgrade once a year. Dependabot or Renovate can open update pull requests automatically, so nobody has to remember.

When you can skip it (and when I'm the wrong person to ask)

Updates matter, but not equally everywhere. These are the cases where I'd spend the money differently:

• A static site with no backend, login or forms carries much less risk. A couple of update rounds a year is usually enough.
• If the system will be shut down within a few months, an upgrade rarely pays off. Restrict access and monitor it until it's switched off.
• If you have an in-house developer with the time and experience, the checklist above is enough. You don't need a contractor.
• If the system is built on something other than PHP, Laravel or JavaScript, I'm not the right person. Find a specialist in that stack.
• If the app is so old that it effectively needs a rebuild, that's a different project from an update and should be scoped on its own.

Next steps

Start by finding out which versions the app runs and when their support ends. If you already work with a developer, ask whether there's a fixed update routine and whether it's written into your contract. My checklist for a software maintenance agreement shows what that contract should cover so updates don't fall through the cracks.

If you'd rather hand the work over, see how I approach Laravel development, upgrades and ongoing maintenance. You work directly with me, the developer writing the code, during CET business hours, and you'll hear back within one business day.

Frequently asked questions

Can I just turn on automatic dependency updates?+

Only for the smallest updates, and only if the app has tests that run automatically. Patch updates can safely be auto-merged when the test suite passes. A developer should look at minor updates, and major updates always need planning and manual testing. Automation without tests just swaps one risk for another: instead of an app that's too old, you get an app that broke overnight.

What should I do when a package is abandoned?+

Replace it, remove it or, in rare cases, take over maintaining it. Composer flags abandoned packages, and the original maintainer often points to an alternative. If the package is small, writing the feature yourself is sometimes faster. The key is spotting it early, because an abandoned package is often exactly what blocks your next framework upgrade.

Is it safe to skip a major Laravel version?+

Only on paper. You can go from Laravel 11 to 13 in one project, but you can't skip the changes from Laravel 12, so you still follow each upgrade guide in order. I prefer to release each step separately, which makes it obvious which step caused a problem. Check the PHP requirement first: Laravel 13 needs PHP 8.3 or newer, which may mean a server change.

Who is responsible for updates when a contractor built the app?+

Often nobody, unless it's written down. A build contract usually ends at launch, and updates after that are ongoing work that has to be agreed separately. Check whether your agreement mentions security updates, version upgrades and response times. If it says nothing, assume the responsibility is yours and agree on a monthly routine with someone who knows the codebase.