Maintain, upgrade or replace a Laravel application?
A broken feature does not automatically require a rewrite. The right next step depends on what is failing, which dependencies remain supported and whether the existing application still fits the work.
Planning worksheet
Choose the next investigation
| Option | When it may fit | What to establish first |
|---|---|---|
| Focused maintenance | A bounded defect or improvement in an otherwise maintainable application. | Reproduce the issue and confirm that the current runtime and dependencies can support the fix. |
| Compatibility upgrade | An unsupported runtime, framework or package blocks safe maintenance. | Map version requirements, package blockers, behavior changes and a supported upgrade path. |
| Partial replacement | One area causes disproportionate change or reliability problems. | Define data ownership and test the connection to the retained application. |
| Full replacement | Essential behavior cannot responsibly be supported or adapted in the current system. | Compare migration, parallel running, retraining and ongoing support with the repair alternatives. |
Keep maintenance bounded
Maintenance fits a reproducible problem such as a slow query, an incorrect permission check or a failed queued export when the surrounding system can still be supported. Define the original failure and a nearby regression check. Completion should demonstrate that the user can finish the task again.
A small patch is a poor substitute for an upgrade when the runtime is unsupported or a required dependency no longer receives fixes. Document that distinction before committing to ongoing support.
Upgrade when compatibility is the constraint
An upgrade preserves useful behavior while moving the underlying framework, runtime or packages to a maintainable combination. Review the relevant Laravel upgrade guides and the package constraints before choosing the order. Test database behavior, authentication, scheduled tasks and workers as well as browser pages.
Use a private rehearsal to expose blockers. A passing dependency install proves that a set of packages can be installed; it does not prove that the application still works.
Ask replacement to justify its disruption
Replacement may be appropriate when the application cannot support essential work, ownership is unclear, or repeated changes are unusually risky. Record the specific constraint. Old code alone is not enough reason to discard working behavior.
Budget for data cleanup, migration rehearsals, integrations, staff learning and the period when two systems may need to run. A partial replacement may solve the difficult area while leaving a stable core in place.
Compare the next year of operation
Compare support needs, change effort, release reliability and the ability to recover from a failed change. Record what remains unknown and who decides after the first investigation. The scope guide helps prepare that brief; the upgrade planner helps organize compatibility questions.