How to Upgrade an Old Laravel, React, Node.js or Mobile Application

Before touching code, build an inventory recording the exact release of each framework, the major and minor of Laravel and the line of Node, plus every dependency. Run composer outdated and npm audit to list stale packages and known advisories before choosing the first target version, because the list shows how many packages block each jump. Support dates keep moving. Check support status on the vendor’s own page, because a version supported a year ago may already be out of support by now.

Laravel’s release notes describe eighteen months of bug fixes and two years of security fixes from each release date, as checked on 8 September 2026. Laravel 10, released in February 2023, is past both windows, and Laravel 11, released in March 2024, passed its security-fix window in March 2026. Node 18 and Node 20 are also past end-of-life, after which a version stops receiving security fixes, according to the Node.js end-of-life page. Check both pages again for current dates.

Read the official guides. Laravel publishes an upgrade guide for each major release, while Node.js and React publish release notes listing breaking changes, and React adds codemods for several of them. Generic advice elsewhere is a starting point at best, since the authoritative list of breaking changes for one jump lives in that framework’s own documentation.

A school-management portal built five years ago on an old Laravel major, with a React frontend several majors behind, shows the problem. A straight jump to the latest releases absorbs several majors of breaking changes at once, with no way to tell which change broke the fee screen. Guides document changes version by version. Upgrade in the same steps.

Take a full backup first. Prove it works by restoring it somewhere else, because a backup that has never been restored is only an assumption about last night’s job.

Run existing automated tests against the current version first, so you hold a baseline of what working looks like before a single dependency changes. If none exist, write basic ones. Cover the flows that earn money or cannot fail, such as login, checkout and the monthly invoice run, because those tests become your proof that nothing broke.

Do all of this in staging. Build a copy that mirrors production closely enough that a pass there is a reliable signal, so the live system stays untouched while the upgrade is under way.

Upgrade one major version at a time, because migration guidance is written for exactly that step and skipping a version skips the documented fixes in between. After each bump, run the test suite and exercise every integration, such as payment gateways, SMS or email providers and third-party APIs. Then click through the screens most exposed to that version’s breaking changes, since automated suites rarely cover every layout and edge case.

Mobile apps follow the same logic. Step through the Android Gradle plugin, the Xcode toolchain and the stores’ minimum target levels, which both stores raise on a schedule unrelated to the framework’s releases. Reread the store guidelines.

Release in stages once staging is clean. If the infrastructure allows, send the new version to a small share of users first, and if it does not, choose a low-traffic window for the switch. Add monitoring aimed at what staging missed.

Keep a tested rollback path for the first few days, so you can redeploy the previous version if error logs, payment failures or tickets reveal a problem staging missed. Retire the old version’s supporting infrastructure only after the new one has run cleanly for a reasonable period, because removing it early turns a recoverable fault into an outage.

Tell support before release day. Brief the people who answer calls on what changes and who to escalate to, because they will hear about a regression before any dashboard shows it.