Is your Laravel app out of date? Upgrade or rebuild?

Software doesn’t wear out, but it does age. A Laravel app built a few years ago still works, until the PHP version it runs on stops receiving security fixes, a package it depends on is abandoned, or nobody dares change anything for fear of breaking it.

When that happens, you’ll face the question every owner of an ageing application hits: upgrade it, or rebuild it? Here’s how to think about it without needing to read the code.

Why old versions matter

Laravel releases a new major version regularly, and PHP does too. Each version gets bug fixes for a while and security fixes for a little longer. After that, nothing. If your app is on a version that’s no longer supported, any newly discovered vulnerability stays unfixed.

That isn’t just a technical worry. It can affect:

• Security: unpatched software is the easiest to attack.
• Hosting: providers eventually drop old PHP versions, forcing a rushed upgrade.
• Hiring: developers don’t enjoy working on very old versions, and it’s harder to find good ones.
• Cost of change: the further behind you fall, the bigger and riskier the eventual jump.

How to check your version

You (or your developer) can find out in a couple of minutes:

1. Look at the composer.lock file in the project, which lists the Laravel framework version.
2. Check your hosting dashboard or ask your host which PHP version you’re running.
3. Compare both with the currently supported versions on the official Laravel and PHP websites.

If either is a few major versions behind, it’s time to plan.

Upgrade or rebuild?

Upgrade when…

• The app does what the business needs and users are broadly happy.
• The code is reasonably structured, even if it’s old.
• You rely on behaviour that would be expensive to recreate.
• You want the lowest-risk, lowest-cost route.

Rebuild when…

• The core design no longer fits the business (the product has changed fundamentally).
• The code is tangled, untested and no one understands it, and upgrading would cost more than starting fresh.
• The data model is badly wrong in ways that cause constant bugs.
• You’re planning a big change in direction anyway.

In my experience, most Laravel apps should be upgraded, not rebuilt. A rebuild tends to take longer and cost more than expected, and it throws away years of small fixes. The exception is when the foundations genuinely can’t be saved.

How a safe upgrade works

A good upgrade is boring, which is exactly what you want:

1. Audit first. Review the code, dependencies, hosting and deployment. You get a plain-English report with a prioritised plan.
2. Add tests around the critical parts. Before changing anything, you capture how the important features behave so you can prove they still work.
3. Upgrade in steps. Move one version at a time rather than leaping several at once. Release each step to a staging site first.
4. Fix and replace outdated packages, and remove ones you no longer need.
5. Release gradually, with a rollback plan and monitoring in place.
6. Document and hand over, so the next upgrade is easier.

Done like this, users shouldn’t notice anything, apart from things getting faster and more reliable.

What it costs and how long it takes

It depends on how far behind you are and how well the app is tested. A modest app a version or two behind can be upgraded quite quickly. A long-neglected one takes longer, because there’s more to untangle. The honest way to get a number is a short audit, which usually costs far less than guessing wrong in either direction.

Keep it healthy afterwards

The cheapest upgrade is the small one you do regularly. A light maintenance arrangement (security updates, dependency checks and monitoring) means you never fall far behind again.

Next steps

If you’re not sure where your app stands, a Laravel health check will tell you what’s healthy, what’s risky and whether to upgrade or rebuild. If you’d like to talk it through, get in touch.