There are still many applications running older versions of Laravel. Whether the upgrade process became too daunting or trapped by an LTS version, I'd estimate 60% of Laravel applications are at least two versions old.
It's easy to think about these old applications with a negative connotation. However, it's often the case these applications are quite successful. If not, they would have been decommissioned or rewritten.
Nay, these applications are very much alive, fulfilling their users' needs. So much so, its developers have not been able to perform an upgrade.
Almost as long as the Automated Shifts have been around, I have offered Human Shifts. Through these I have successfully upgraded over 200 Laravel applications to the latest version. Many times despite previous failed attempts.
This post serves mainly as the sales pitch for those inquiring about Human Shifts. It also shares my opinion on why upgrading old Laravel applications is not something your team should do.
The main reason Laravel applications are not upgraded is due to lack of resources. Either you can't justify the priority compared to incoming requests or you can't dedicate a developer to the project.
At some point though, you will need to upgrade. Often for performance or security reasons due to running an older version of Laravel. Sometimes there may be a new feature of the framework that is just too large to reinvent.
As silly as that latter might seem, many old Laravel applications fork packages, or even the framework, to mimic new features opposed to upgrading.
That's really what this boils down to. Everything is a tradeoff. Ultimately, the upgrade is never chosen. But this becomes circular reasoning.
You don't have time to upgrade because you've never taken the time to upgrade.
Ceasing all new work and dedicating the entire team to paying off years worth of technical debt is simply not possible. It's the grand rewrite in the sky and it doesn't work.
I on the other hand do work. I can be added as external capacity. I can focus strictly on the upgrade. Your team can continue working. When the upgrade is verified, I can even help merge the work back together.
Another hard truth of the upgrade is your team won't learn anything. There's nothing about the upgrade process that matters for day-to-day development.
Most of the nuances between the various Laravel versions is throw-away knowledge once you are on the latest version.
Sure, there's a few educational tidbits. But these are likely something your team already knows either from working on other new Laravel projects or staying current.
As the creator of Shift this knowledge is not wasted on me. Shift requires me to know every detail of the upgrade process between every version.
I have reviewed the upgrade path between 4.2 and 6.0 and all the versions in between. I have personally handled every Shift support email. I have reviewed analytics on over 17,000 Laravel applications.
I never liked the term expert. There's always more to learn. But you'd be hard-pressed to find anyone more knowledgeable with the Laravel upgrade process.
This capacity and knowledge combine to make me more efficient. I'll be more focused and faster than your team.
Too often developers use the upgrade process as an opportunity to rewrite pieces of the application. This is why most upgrades fail.
Let me focus on upgrading the application to a modern version. Your team can then focus on rewriting or refactoring after the upgrade is done.
I'm also faster. I have several scripts to help modernize old applications. Scripts to
namespace classes, convert deprecated methods, rewrite code using abandon packages popular in old versions of Laravel.
I have upgraded standard Laravel 4.2 applications to Laravel 5.8 within 3 hours. I upgraded super complex, highly customized applications using dozens of packages in under 20 hours. So the turn-around time on most of these upgrades is less than a week. Think about that, you could be running the latest version of Laravel by next Monday.