Laravel Upgrade Checklist: How to Move an Old App Safely

If you're running an older Laravel app, you've probably put off the upgrade because it feels risky: something will break, and nobody is sure what. This Laravel upgrade checklist turns that worry into a plan you can follow, whether the app is a couple of versions behind or still on a very old release.

The good news is that upgrades rarely fail because of Laravel itself. They fail because nobody checked the PHP version, the packages, the tests or the deployment plan first. Do those four things well and the upgrade itself is mostly routine.

If you'd rather hand it off, that's the core of my legacy application modernization service. Otherwise, I'll cover why it matters now, what to check before you touch the code, how to upgrade step by step, how to test and deploy safely, and when it's smarter to bring in help.

Why upgrading an old Laravel app matters

Every Laravel release has a support window: bug fixes for 18 months and security fixes for 2 years. Once a version is past security support, vulnerabilities are no longer patched for it.

As of October 2026, Laravel 13 is the current major release, supporting PHP 8.3 to 8.5. Laravel 12 still receives security fixes until February 2027. Laravel 11 ended security support in March 2026, so any app on it or older is already running without security patches. Check the Laravel release notes for the current dates before you plan, because they change as new versions ship.

Old versions also hold you back in practical ways:

• Security: unpatched framework and package vulnerabilities.
• PHP: the version of PHP your server runs, and its own support window, which you can check at php.net.
• Packages: new package releases stop supporting old Laravel versions, so you can't add features or fix bugs that depend on them.
• Hiring and cost: developers prefer current versions, and the longer you wait, the bigger and more expensive each upgrade becomes.

If your app is old enough that a straight upgrade looks unrealistic, my notes on safely modernising a Laravel 5 application cover when a staged rebuild makes more sense.

Before you upgrade: the pre-flight checklist

Most of the risk is removed here, before any code changes. Work through this list first:

• [ ] Know your current versions. Laravel, PHP, your database server, and every Composer package. Run composer show and php -v.
• [ ] Read the upgrade path. Note every major version between your version and the target. The official upgrade guide covers one major version at a time.
• [ ] Check PHP compatibility. Your target Laravel version has a minimum PHP version. If your server is behind, plan the PHP upgrade as its own step.
• [ ] Audit your packages. Run composer outdated. List every package that is abandoned, unmaintained or doesn't support your target version, and decide whether to replace it.
• [ ] Get a working backup and a staging copy. A recent database backup, a copy of the production environment and a way to restore both.
• [ ] Check your tests. If you have tests, make sure they pass now. If you have almost none, write tests for the most important flows first (login, checkout or billing, key reports).
• [ ] Pin down the critical paths. List the five or ten things that must never break: payments, imports, scheduled jobs, emails, integrations.
• [ ] Freeze feature work. Upgrade in its own branch and avoid mixing big new features into the same release.

If you have no tests at all, don't skip this step. A few well-chosen tests around money, data and logins give you a safety net for the whole upgrade. I describe a practical approach in testing strategy for Laravel SaaS.

The upgrade steps, in order

Upgrade one major version at a time. Jumping several versions in one go makes problems much harder to trace.

1. Upgrade PHP first, if needed. Make the app run on the newer PHP version while it's still on the old Laravel version, where possible, and fix any deprecation warnings.
2. Update packages that block you. Move to versions that support both your current and target Laravel versions, where they exist.
3. Follow the upgrade guide for the next major version. Update composer.json, run composer update, then work through the guide's list of breaking changes one by one.
4. Run the tests and fix failures. After each major version, get the tests green before moving to the next.
5. Check configuration and the application skeleton. Newer versions change default config files and structure. Compare yours to a fresh install and bring across what matters.
6. Repeat until you reach the target version.
7. Clean up. Remove deprecated code, update your code style and update the remaining packages.

Tools can speed this up, but they don't replace review. Laravel Shift automates much of the work for a fee and opens a pull request for you. Rector can apply many code changes automatically, and Laravel Pint can restyle code. Treat their output as a first draft you read, not a result you trust.

Testing the upgrade

Passing tests are necessary, not sufficient. Before going live:

• Run the automated tests, including any browser tests, on the upgraded branch.
• Test the critical paths by hand on staging with realistic data: sign-up and login, payments, file uploads, emails, queued jobs and scheduled tasks.
• Check the queue and scheduler. Background work is where upgrades often fail quietly.
• Compare performance on key pages and reports before and after.
• Watch your logs on staging for new warnings and deprecations.
• Test the integrations with third-party services, using sandbox accounts where they exist.

Deploying without drama

A safe deployment matters as much as a safe upgrade:

• Deploy outside your busiest hours and tell the people who depend on the app.
• Take a database backup immediately before deploying.
• Use a deployment process that can roll back. Running git pull, composer install and php artisan migrate on the live server is how users hit errors mid-deploy, and I describe a better approach in zero-downtime deployments for Laravel.
• Restart queue workers after deploying so they load the new code.
• Watch error tracking, logs and your key flows closely for the first day.
• Keep the old release available so you can switch back fast if something goes wrong.

Real examples from my work

I led the modernisation of the React frontend and Laravel backend on Violerts, a PropTech SaaS platform with multi-agency data ingestion, asynchronous scraping, real-time alerts and Stripe-powered billing. In a product like that, queues, billing and integrations are exactly the critical paths you list and test before any upgrade.

On the Jamaica freight-forwarding audit, the starting point wasn't a Laravel version at all. It was a Core PHP and MySQL platform, so I audited the workflows, database structure and dependencies first and assessed the path toward a future Laravel migration. When the app is that far behind, understanding it comes before changing it. I wrote about the follow-on work in migrating a legacy Core PHP platform to Laravel.

When to get help

Upgrade it in-house if you have tests, a staging environment and someone who knows the codebase. Bring in help if:

• the app is many major versions behind;
• there are no tests and nobody fully understands the code;
• key packages are abandoned and need replacing;
• the app earns money and can't afford downtime.

A senior Laravel developer can run the upgrade, or audit the app first and give you a clear plan and estimate. Here's what to check when hiring one.

Frequently asked questions

How long does a Laravel upgrade take?

It depends on how far behind the app is, how many packages need replacing and how good your tests are. A small, well-tested app one version behind can take days. A large, untested app many versions behind can take weeks or longer.

Can I skip Laravel versions?

You can reach a recent version without stopping everywhere, but the safest approach is to follow the upgrade guide for each major version in turn. Skipping steps makes it harder to find which change broke something.

Is it risky to upgrade a Laravel app?

The risk is manageable with a backup, a staging copy, tests on your critical paths and a rollback plan. Staying on an unsupported version carries its own risk, because security issues stop being patched.

Should I upgrade or rebuild?

Upgrade if the app is structurally sound and the pain is mainly the version. Consider a staged rebuild if the code is tangled, there are no tests and the framework is very old.

Key takeaways

• Check PHP, packages, tests and your deployment plan before touching the code.
• Upgrade one major version at a time and get the tests green after each.
• Tools like Laravel Shift and Rector help, but you still review every change.
• Test the critical paths on staging, including queues, the scheduler and integrations.
• Deploy with a backup and a rollback plan, and watch closely afterwards.

If you'd like a clear plan and estimate for upgrading your Laravel app, book a call and I'll help you map the safest route.

---

Originally published at aqibjavaid.site.