Should I upgrade Laravel before rewriting?

Usually, do not decide between an upgrade and a rewrite from the framework version alone.

An old Laravel version may be a real risk, but it may also be only one visible symptom of a system that is difficult to understand. A rewrite can produce a newer codebase while carrying the same hidden pricing rules, permissions, data assumptions, integrations, and operational workarounds into a second system.

Start with the system, not the version

Before choosing a direction, map enough of the application to answer:

• Which workflows are business-critical?
• Where do important rules live: models, actions, jobs, database constraints, admin screens, integrations, or team habits?
• Which parts are covered by tests or production evidence?
• What does the current version prevent you from doing safely?
• What is the smallest change that would reduce uncertainty?

An upgrade becomes more attractive when the existing behavior is understood well enough to protect while dependencies and framework assumptions are changed. A rewrite becomes easier to justify when the current boundaries are genuinely understood, the data migration is realistic, and the cost of preserving the existing shape is higher than replacing it.

A useful first move

Try a narrow investigation before committing to either project. Trace one important workflow from its entry point through validation, business rules, persistence, jobs, and external effects. The result is more useful than a generic rewrite estimate because it shows where the real risk lives.

The goal is not to avoid large changes forever. It is to make the next decision from evidence instead of from discomfort with an old version.

If you need help making that first decision inside a working Laravel application, see how I help with inherited systems.